本人不才,仅仅比较喜欢数据库,也来谈谈吧（仅就关系数据库论,
包含：ACCESS、SQL Server、SyBase、MySQL、Oracle、DB2等国际上最流行的数据库系统）:
本人认为,不能说好的数据库,只有适合于应用的数据库,在不同的应用中,数据库的建立规则和依赖性以及复杂程度都有可能不一样。
  在数据准确性要求高的数据库系统中,一般对表的设计是清晰的结构,而且极连性质非常严格,在1:1的关系模式中尽量采用同一张表来完成对其的设计,因为在统计查询中经常使用相同的数据来完成任务,而数据如果采用分离设计方式,就会降低查询效率。但是,在其他如同网站或一般的管理系统中,未了保证数据的逻辑存在性,也就是在数据始终保证存在(为了备用,如果数据冗于太大可以用光盘备份出来)而在逻辑上保持删除，也就是说，当用户进行某些操作的时候，对于用户来说，它已经不存在了，这可以用某些人工标志位来完成。
  
当然在标准SQL中（ISO组织的标准），实体首先要保持完整性和独立性，实体和实体之间存在关系，有:1:M的关系，有M:N的关系，特殊的有1:1的关系。这些关系可以解决数据一致与冗于的问题，但实际的系统中依赖于某些需求是无法完全理想化地实现的去掉冗于的，那么就需要我们用一些手段来弥补这些错误，而且在建立的关系规则越加严密对于应用程序的开发者的要求就越高，所以我说要针对实际的系统而论之。
  
至于什么是好的数据库，我个人的看法是这样的，首先数据库至少要符合“第一范式”，也就是属性的原子性，这是最为基本的规则（说到这里顺便说一下：属性的原子性是相对的，针对不同的应用，比如：美国人习惯把‘姓’和‘名’分开成两个属性，而中国中习惯把姓名作为一个属性来看待）。
  然后去追求第2、3范式的要求（要求同实体内部的各属性必须都依赖于主键存在，而主键外其它属性不可以相互依赖或通过计算得到对方的结果），不能完全达到，也需要尽量去满足它的要求，因为某些具体应用如果使用完全范式去设计，程序编写将十分困难，对于级别比较底的系统没有必要那么去完成，至于以后它需要提高级别，可以给它做升级版本。
  至于第4、5范式就更加难了，一般的系统都设计不到那么深的境界，至少我还没有用过，我觉得这种设计数据库的方式数据一种完全理想化的方式了。
其实，国际标准组织之所以建立这些规则就是为了让解决数据处理的两大历史上（文件系统阶段）的问题：数据的冗于性太大，数据的一致性无法保持还有一些小问题：查询效率底下（依赖于一些应用程序，算法由人工设计，文件系统访问速度很慢，多个实体关系太小，只能逐步查询所需要的每一个实体，然后拼接数据，数据库系统可以由地层建立关系一次性查询完毕，从计算机的角度来说是叫做串行操作和并行操作的区别），查询单位只能以实体作为单位（数据库系统可以以属性为单位来进行查询，在数据库的关系模式分析中称为：投影）。
  所以要设计好的数据库系统就要以上面的历史问题作为数据库系统问题的宗旨，然后尽量消除上述的问题，形成一个基于业务模式的体系结构化数据库系统（数据库系统依赖于业务而生成，同一业务之中的数据库表必然存在某些关系，需要为他们建立某些严密的关系模式，体现数据库的数学结构，和你合作开发项目的团队将以此作为基本数据来源，他们对于一个好的数据库结构搭建后对项目也会更加有信心，上述所说的业务中的数据库，但不同业务中的数据实体也可能存在联系，那要看具体的应用需求了）。
  
对唯一标识的认识：需要认识到，一般来说，你在数据库系统中建立任何一个实体或关系都必须有一个主键，它是唯一标识实体或关系存在的工具，就像每一个人的脸一样，即使是双包胎也有点区别，我们才可以区分不同的人，系统内部是一样的，就需要建立唯一标识，有可以是实体自己的本题存在标识，也可以是人工根据具体应用加上的逻辑唯一标识，这些东西又牵涉到一大堆的东西，要达到这一行的上乘境界需要深厚的理论功底+多个不同档次和不同应用的项目开发经验。
  
就这么多吧，肤浅之谈，若要深入，请参考相关书籍（最好是国外的）。