标签：mysql database-design mysql-workbench normalization schema
我正在根据第三方供应商的数据建立车辆记录数据库.有3种型号：车辆,变速箱和适配器.
车辆和变速器都是1：n适配器.技术上变速器只是具有附加变速箱柱的车辆,而车辆除了车辆柱之外还包含燃料系统柱.我无法确定将数据合并到一个规范化集合中的最佳方法.
以下是我的数据的一些示例：
传输表
车辆表
数据透视表
如您所见,Transmissions和Vehicles基本上与trans_type / fuel_system列(分别)和更高版本相同.例如,我突出显示的Vehicle与使用engine_code LML显示的2nd Transmission相同.
理想情况下,我希望最终只得到一个车辆数据表.例如,如果我要合并突出显示的记录,我最终只能获得2013年GMC Sierra 3500 HD的2条记录：
一辆配备6.0升V8发动机,另一辆配备6.6升V8发动机,以及各自的燃油系统和变速箱.
枢轴表也将被组合,这意味着我需要以某种方式用组合数据中的新ID替换旧ID.
以下是我对如何处理此问题的看法：
>标准化类似的列(品牌,型号,引擎,传输)
>简单地将fuel_system和trans_type列拆分成他们自己的表(但是这对我来说没有任何帮助,它只是让事情变得更容易管理,直到我弄清楚如何组合)
>创建一个包含两个表中所有列的新表,并插入车辆和传输中的数据,填写空白(即更新记录匹配的fuel_system,反之亦然,然后开始清理重复项).
我为冗长的帖子道歉,但我还没有在我的搜索中找到任何真正概述这个过程的内容.欢迎任何意见或建议,并提前感谢您.
解决方法:
功能依赖和规范化
为了执行涉及第二种和更多正常形式的规范化练习 – 按照Dr. E. F Codd的数据关系模型,首先必须知道属性之间的相关功能依赖性(简称FD)(通常描述为列) )adapted mathematical relation(通常被描绘成一张桌子).这种练习属于数据库抽象的逻辑层次.这就是为什么,为了解决您声明的获得标准化集的意图,我通过评论要求提供有关适用FD的信息.
例如,涉及假设属性Foo和Bar的FD可以被描绘为Foo→Bar,其又可以被读作“属性Foo确定属性Bar”或“属性Bar由属性Foo确定”.通过这种方式,人们可以区分(a)一个或多个属性,或属性的一个或多个组合,它们是关系的关键或关键,以及(b)区分不属于或不属于的属性. ,钥匙或钥匙.
关于您描述的场景,让我们假设名为“传输”的网格是数学关系的具体表示.关于标记为子模型,body_code,engine_code,引擎,desplacement,cylinder,trans_type,trans_code和qualifier的列的值,可以说：
>某些(engine_code和trans_code)似乎是由被称为关系的关键字的值决定的,比如说,车辆 – 即(模型,品牌,年份)的组合.
>某些(transmission_type和qualifier)似乎是由称为TransferAdaptor(即trans_code)的关系的键的值决定的.
>某些(engine_type,displacement和cylinder)似乎是由一个被称为Engine的关系的键值决定的,即engine_code.
但这些都是简单的假设,基于我对上述网格中包含的信息的个人解释,显然我对所涉及的业务环境一点也不熟悉.因此,为了摆脱那些不必要和有问题的假设,你必须采访业务专家,他们将帮助你识别FD,这将反过来指导你进行适当的规范化和布局数据库结构数据库管理专业所需的精度.如果没有您可以求助的业务专家,那么您将不得不深入研究数据集,观察数据的使用和意义,并仔细分析感兴趣的信息之间的相互关系,以确定您自己的重要FD.
标准化集
具有规范化数据库有助于避免在所考虑的关系(表)的属性(列)之间存在不期望的依赖性时最终出现的更新/修改异常(影响INSERT,UPDATE和DELETE操作).在例如存在(i)依赖于非关键属性的关系的属性,或者(ii)依赖于复合-ie,多属性关键字的部分的情况下,设计者必须分解关于两个或两个以上的关系.
因此,大多数情况下,规范化集合由各种关系组成,每个关系意味着在其元组(行)中恰好包含一种特定类型的事实.相反,非标准化和非标准化集合由一个或多个关系组成,这些关系在其元组中包含多种类型的事实.
从概念抽象层面开始设计数据库
另一方面,您可以从不同的角度设计相关的数据库,首先从纯粹的概念角度分析感兴趣的事物类型的结构和关联 – 或关系或关系 – 而不考虑关系(表格) ),属性(列),约束和规范化.当然,这种方法还需要数据库设计者和业务专家之间的密切沟通,或者在没有业务专家的情况下,数据库设计者需要深入了解信息需求和业务环境的特征.
示例业务规则
因此,我将汇总一些假设的业务规则,这些规则将有助于创建一个说明性概念架构,仅基于对问题中包含的信息的假设.
车辆是：
>主要由Model,Make和Year的一个组合来识别
>仅由一个引擎移动
>配备一个TransmissionAdaptor
> ……
引擎：
>主要由一个EngineCode识别
>仅由一个EngineType编目
>只有一个位移
>只包含一种类型的气缸
>只提供一个FuelSystem
>安装在零个,一个或多个车辆上
> ……
TransmissionAdaptor是：
>主要由一个TransmissionCode识别
>按一个TransmissionType分类
>安装在零,一个或多个车辆上
> ……
燃料系统：
>主要由一个名称标识
>仅按一种FuelSystemType进行分类
>只有一个压力
>安装在零个,一个或多个车辆上
> ……
如所示,(a)可能的实体类型相关性的属性与(b)可能的实体类型本身之间的假设关联类型之间的假设关联类型已经以相对清楚的方式陈述.
显然,这些规则完全是介绍设计数据库时可以遵循的方法的媒介.被设计为个人解释,当然应根据实际商业环境特征进行确认,驳斥或改编.
有时,数据库设计者会绘制一个描绘概念模式定义的图表,以便提供一个图形工具,帮助所有感兴趣的技术方和非技术方之间进行通信.
当这个阶段的结果稳定到一定程度时,人们可以开始考虑通过逻辑层次结构更自信地表示这些概念方面.
a顺便说一句,指出概念关系与逻辑关系非常不同是恰当的.
说明性的SQL-DDL逻辑级设计
接下来,我创建了以下四个表,它们代表了上面阐述的概念级公式：
CREATE TABLE TransmissionAdaptor (
TransmissionAdaptorCode CHAR(10) NOT NULL,
TransmissionType CHAR(30) NOT NULL,
--
CONSTRAINT TransmissionAdaptor_PK PRIMARY KEY (TransmissionAdaptorCode)
);
CREATE TABLE FuelSystem (
Name CHAR(6) NOT NULL,
FuelSystemType CHAR(10) NOT NULL,
Pressure CHAR(10) NOT NULL,
FuelSystemName CHAR(30) NOT NULL,
--
CONSTRAINT FuelSystem_PK PRIMARY KEY (Name)
);
CREATE TABLE MyEngine (
EngineCode CHAR(3) NOT NULL,
EngineType CHAR(8) NOT NULL,
Displacement CHAR(3) NOT NULL,
Cylinders CHAR(3) NOT NULL,
FuelSystemName CHAR(6) NOT NULL,
--
CONSTRAINT Engine_PK PRIMARY KEY (EngineCode),
CONSTRAINT Engine_to_FuelSystem_FK FOREIGN KEY (FuelSystemName)
REFERENCES FuelSystem (Name)
);
CREATE TABLE Vehicle (
Model CHAR(20) NOT NULL,
Make CHAR(10) NOT NULL,
MyYear SMALLINT NOT NULL,
EngineCode CHAR(3) NOT NULL,
TransmissionAdaptorCode CHAR(10) NOT NULL,
--
CONSTRAINT Vehicle_PK PRIMARY KEY (Model, Make, MyYear),
CONSTRAINT Vehicle_to_Engine_FK FOREIGN KEY (EngineCode)
REFERENCES MyEngine (EngineCode),
CONSTRAINT Vehicle_to_Transmission_FK FOREIGN KEY (TransmissionAdaptorCode)
REFERENCES TransmissionAdaptor (TransmissionAdaptorCode)
);
从现在开始,人们将处理逻辑级元素,其中表格具有明确声明的基于明确概念架构的键,因此需要进行适当的常规形式评估练习以测试设计的完整性.
就个人而言,我发现上面描述的设计顺序,即
>(1)概念性表述⟷(2)逻辑表示⟷(3)通过正常形式进行测试
比直接使用“隔离”功能依赖更自然,因为它帮助设计人员以彻底的方式从不同的抽象层次理解场景.
进一步考虑
系统指定的代理人
您可以注意到,我没有附加一个额外的Id列(通常添加以包含系统生成的代理键值)到任何这些基表,因为这样做只会阻碍(概念)建模和(逻辑)规范化任务.一旦你有一个具有相应约束的稳定结构,那么评估添加该非数据工件是有益的特定情况将是合适的.
列数据类型
未详细讨论的一个重要因素是与每列相关的特定域.因此,当您继续设计数据库时,必须确定每列的最合适的数据类型和大小.
数据推导
具有如上所述的逻辑布局,您必须使用派生表(例如,通过SELECT操作声明的表,这些表收集来自一个或多个基本列或其他派生表的列)以获得如图所示的信息,例如,在您的传输网格中.
当然,可以将派生表定义为可以进一步查询的视图,以便例如易于编写未来数据操纵操作的代码.
研究这一点可能是有用的,看看你是否能够完成你所声明的目标,理想情况下,最终只能得到一个车辆数据表.
物理层面的方面
物理抽象级别是明确需要注意的另一点,因为最方便的索引的配置直接与数据库的最佳功能相关联(例如,读写速度,可伸缩性).不用说,您必须在这方面考虑数据操作操作(或查询)的趋势.通常,您修复了支持所涉及列的索引,例如,在WHERE和JOIN子句中.
MySQL作为数据库管理系统的众多缺点和缺点之一是它不提供对“索引”或“物化”视图的内置支持,因此如果你想构建一个数据库,这个因素显然是值得考虑的.有效地工作.
其他重要的物理层面方面是,例如,以最佳方式设置所涉及的硬件(硬盘驱动器,存储器,处理器等),数据库管理系统,操作系统,网络带宽等.
附录
在最近的评论交互中出现了在设计数据库时拥有对所关注业务领域的全面了解的重要性的证据,其中@Rick James提出了关于某些实体类型的相关考虑,它们在您的场景中的相应关联类型和基数比率：
It looks like transmissions:adaptors is many:many, not 1:many. Please clarify.
…你回答如下：
Yes, this is correct. Transmissions have their own adaptors and FuelSystems have their own adaptors. A transmission belongs to zero, one or more transmission adaptor(s) and a transmission adaptor can belong to zero, one or more transmissions.
因此,如您所知,有必要对这些概念实体类型进行建模,即：
>传输,TransmissionAdaptor,FuelSystem和FuelSystemAdaptor,
和连接关联类型,即：
> Transmission-TransmissionAdaptor和FuelSystem-FuelSystemAdaptor,
这样它们就可以按照要求的精度反映您的业务领域特征.
一旦所有相关方面都在逻辑级DDL设计中与相应的表(每个实体/关联类型为一个),列,数据类型和约束表示,您可能希望评估所涉及的功能依赖性以提供强大的,标准化,系统.
标签：mysql,database-design,mysql-workbench,normalization,schema 来源： https://codeday.me/bug/20190806/1600055.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。