该行业的一个巨大问题是，尽管有优秀的供应商提供了用于真实建模的良好工具（生成符合标准的图表），但我们也有供应商提供各种荒谬的图片和不合规的图表。这使得 IT 人员能够制作出好看但完全没有意义的图表。关键是，这些可怕的小工具实际上给了人们信心，他们已经建立了一座良好的桥梁，一个良好的数据库。首先，他们创建一堆电子表格，将其加载到一个称为“数据库”的容器中，软件帮助他们认为他们现在有了一个“数据库”；然后他们使用工具对“数据库”进行逆向工程以生成“数据模型”。这给了他们虚假的信心；他们不知道自己有一桶鱼的有趣图片，如果有人指出这一点，他们会感到被冒犯。坚持使用通过声明和认证符合标准的工具，并丢弃那些不符合标准的工具。
微软臭名昭著的错误引用，将汽车行业的进步与微软的“进步”进行了比较，汽车行业对此做出了公开回应，理所当然的愤慨，并抹去了比尔·盖茨脸上的笑容。 Sun Microsystems 也做出了著名的回应，但我怀疑 MS 圈子是否知道这一点。请注意，MS 的可信度是通过绝对数量来获得的：在 MS 爱好者之间提供和交换不断变化的“信息”的互联网站点的数量。他们脱离了真正的资格和标准，并错误地认为单一供应商惯例和部分性能，使用漂亮的图片，实际上构成了“软件”。
Before answering the "notation" question, which is the small visible issue on the surface, we need to understand the issues that underpin it, which lead to the surface issues. Otherwise the relevance to the question is reduced to personal preferences; what some product or other provides, whether it is free, etc.
Standards
I assume that the reader has no argument that bridges built for the public out of the public purse (as opposed to hobby bridges built on private land for personal use) need to have standards, in order to ensure that they do not fall over; that they can carry the declared traffic, and that people will not die while using them. The intended standards are first presented by highly acknowledged and recognised engineering experts, and heavily practised and tested by their peers, eventually attaining the status of a Standard, and being declared as such by government standards bodies. The authorities then simply identify the standards that all suppliers must conform to, in order to supply bridges to the government.
It is a waste of time to engage is discussion with non-compliant engineering companies, as what or why their sub-standard offering is worthy of evaluation. Or to look at diagrams that have specific information (demanded by the Standard) missing from them. Or to talk to companies presenting themselves as bridge builders, but who have no civil engineers on the payroll.
Standards are Normalised
Another important aspect of Standards, is that there is no repetition. The bridge building standard only has to refer to the electrical standard for all wiring on the bridge, it does not repeat the content. Standards are Normalised. This allows each Standard to progress and change (eg. as appropriate, due to new building materials becoming available), without affecting other standards or their compliance.
Likewise, Standards do not compete. If one complies with the bridge building standard, there is no danger that one has broken the communications standard.
Standards relate to Higher Principles
Standards are thus the higher principles that every supplier who genuinely supplies quality and performance, will eagerly comply with. And the others will range from reluctant compliance all the way through to ignorance that an applicable standard exists.
Standards are Not a Notation
Third, the Standard is not merely a set of symbols and notations that the diagram must comply with. The unqualified and inexperienced bridge builders may say it is, because of their low level of understanding of the entire set of knowledge required to build faultless bridges, but no. The Standard is always a methodology or set of explicit steps, which are prescribed for the process, which if adhered to, produce the decisions that need to be made at each step, in a progression, so that each decision can be based on previous decisions that have been confirmed, and that can be relied upon. A simple diagram progresses through prescribed standard-compliant stages or phases, with complexity and notations being progressively added, such that the final diagram is compliant.
Standards are Complete
The fourth issue has to do with ensuring that the information conveyed in a diagram is complete and unambiguous. The Standard ensures that the information required is complete. The exercise of the methodology means that ambiguities have been formally identified and resolved. Sub-standard diagrams do not include that requirement of essential Standard information, they are incomplete and contain ambiguities.
Standards are Easy
In addition to the confidence of achieving a certain level of quality, it is actually easier and faster to go through the standard methodology. It is absurd for the non-complaint companies to retro-fit their diagrams by merely supplying standard notation to them. The absence of the prescribed process is visible to any standard-aware person, and the diagram will conflicted (the components s lacking integration).
Responsible, aware customers (government departments, aircraft manufacturers ... companies that expect to be around in the next decade) have reasonable expectations that the software it purchases from suppliers will be of a certain quality; easy to enhance and extend; perform well; will integrate easily with other software; etc.
Lack of Standards in IT
The problem with the IT industry is, unlike the car manufacturing or bridge building industries, since it has exploded in the last 30 years, we have been flooded with providers who are:
not educated in IT (do not know the formal steps required for the project)
not qualified in IT (have no idea re what is right and wrong)
not experienced in IT (they are experienced in what they know)
unaware of Standards
work in isolation from their qualified peers
work in the comfort and ease, the isolation, of a single vendor's "products"
have false confidence based on success in isolation
Unskilled and Unaware of It
This has been the subject of much research and publications, it is not merely my professional opinion, the credit goes to the academics who did the hard work to sift through and identify exactly what the specific issues are.
So in terms of the whole population of IT providers, IT companies as well as IT employees in non-IT companies, the awareness of quality, of the standards required to provide quality, and their importance, is much lower than it was 30 years ago. It is a 'build and forget' mentality; if it doesn't work, throw it out and build another one. But for the big end of town, the responsible aware customers, that is not acceptable.
Standards are Not Single-Vendor
By definition, Standards are arrived at by multiple vendors, at the international level.
One huge problem in the industry is, in spite of having good vendors who supply good tools for real modelling (the resulting diagrams which comply with Standards), we also have vendors who supply a full range of absurd pictures and non-compliant diagrams. This allows IT people to produce good-looking but completely meaningless diagrams. The point is, these horrible little tools actually give people confidence, that they have built a good bridge, a good database. First they create a bunch of spreadsheets, which they load into a container called a "database" and the software helps them think that they now have a "database"; then they use a tool and reverse-engineer the "database" to produce a "data model". It gives them false confidence; they are unaware that they have a funny picture of a bucket of fish, and they feel offended if anyone points that out. Stick with the tools that are standard-compliant by declaration and certification, and toss those that aren't.
The single-vendor non-standard tools may give one comfort and ease, and a false sense of confidence, in isolation. But they cannot be used if one wants to achieve diagrams that convey all required info; confidence that is gained by acceptance of qualified peers; quality that is derived from a prescribed set of steps; confidence that one does not have to keep on reworking the model.
Conventions are Not Standards
And before anyone points out the the horrible tools are "de facto standards", no they aren't, they are common conventions, with no reference to Standards, and we should not confuse the two by using the word "standard" in reference to them. The way one gets out of bed and makes coffee is a convention, possibly very common, but it is not a "standard". Your common vendor, in their commercial interest, may have commercialised you into believing that there is only one "standard" coffee machine and one "standard" coffee bean, but that bears no relation to the Standards to which the coffee machine manufacturer must comply, or the Standard of coffee bean imported into the country.
There is the mis-quotation that MS is infamous for, comparing the progress of car industry to the "progress" of Microsoft, which the car industry responded to publicly, with justified indignation, and wiped the grin off Bill Gate's face. Sun Microsystems also responded, famously, but I doubt that is known in MS circles. Note that MS credibility is gained by sheer volume: the number of internet sites providing and exchanging ever-changing "information" among MS devotees. They are isolated from genuine qualifications and Standards, and falsely believe that single-vendor conventions, and partial performance, using nice-looking pictures, actually comprise "software".
Standards are Not Expensive
That does not mean you have to buy expensive tools. For small projects, it is quite acceptable to draw diagrams using simple drawing tools, because the compliance-to-standards is in the cranium, in the prescribed methodology, not in the tool, and therefore it is possible for a qualified, standards-aware person to produce standard-compliant drawings (for small projects) with any almost tool. And note that those horrible tools which misrepresent themselves do not provide the standard notation; the vast majority of "data models" and "entity relation diagrams" out there, are grossly sub-standard.
Standards re Relational Databases
Standards or precise definitions or specific guidelines, for the following have existed for over 30 years. In progressive order, each containing the previous:
Normalisation (for any Database) (a Standard is not required, it is an engineering principle; common across many disciplines; a simple process for those qualified; and absence of it is easily identified.)
Relational Databases The Relational Model: E F Codd & C J Date
The famous Twelve Rules of Relational Compliance E F Codd
Relational Data Modelling IDEF1X; 1980's; NIST Standard FIPS 184 of 1993
There are many suppliers who have practised these methodologies, as prescribed, thereby conforming to the Standards, for up to 30 years.
Note, there is only one Relational Data Modelling Standard, there is no conflict.
Note, the notation is just what you see on the surface, the result, however it does identify that other notations have info missing from them, and the underlying methodology was not followed.
Note well, that Normalisation pre-dated the Relational Model, and was taken as given; that is why the RM does not have specific references to Normalisation as a principle, and only identifies the Normal Forms, in terms of the requirement for Relational Databases.
If you are genuinely qualified as a Relational Database Modeller, you will be intimately familiar with the first three; if you are a standard-compliant Relational Database Modeller, you will be intimately familiar with the fourth. Again, you cannot reasonably expect to comply with the Standard merely by learning the IDEF1X Notation, you need to actually learn and practise the methodology, but learning the Notation may be a reasonable introduction.
[Compliance to] Standard is Demanded [by Some]
There are aware, responsible customers, who demand compliance with these Standards.
And then there is the rest of field, both the unaware customers and the unaware suppliers, and everything in-between.
Which Notation ?
For most standards-aware practitioners, there is no need to discuss "which notation to use", given that there is only one Standard. Why would I draw a diagram (using either an expensive tool in a large project, or a simple drawing tool to answer a question on Stack Overflow), using some other notation when there is no other standard ? Why would I convey less than the Standard information, when I can convey the Standard info just as easily ? Why would I avoid using the Standard, when I know that using the Standard provides the formal confidence that the Data Model is correct, and will stand up to scrutiny (as opposed to the imagined confidence that is punctured by most cursory questioning) ?
If, and when, some qualified, recognised organisation comes up with a new methodology (and believe me, they do, all the time), we look into it. If and when the methodology achieves academic peer recognition and acknowledgement, we will take it seriously, try it out, become adept with it. If and when it is declared a Standard by the international standards bodies (as opposed to single vendor), we will provide it. Until then, we provide the full compliance to Standards that do exist.
Future Notations & Conventions
The couple of hundred single-vendor offerings in the last 20 years were not worth the time spent in investigation. Therefore single-vendor conventions, be they labelled "standards" or not, are not worth the time spent in investigation. In fact, since the Standard exists, and pre-dated the advent of the single vendor, any single-vendor offering would be an implicit declaration that they cannot comply with the Standard, and they are offering an anti-standard as a substitution.
Responses to Comments
The easiest way to refute an amateur's allegation that some rubbish is a "standard" is to ask for its ISO/ANSI/IEC/NIST/etc publication data. As per (4) above IDEF1X is a published Standard, easy to look up.
MS is famous for publishing anti-standards, and calling them "standards". The correct term is "convention". Wikipedia might call some MS notation a standard this week, but I've already noted that Wikipedia is not a reliable source. Remember, a single-vendor offering is, by definition, not a standard.
IDEF1X is also a business process modelling standard
Not quite. The IDEF1X link will take you to the organisation that is most responsible for publicising it and educating people about it. If you check the tabs on that page, you will find several standards. One of the great powers (beauties?) of Standards is that they are integrated:
IDEF stands for I ntegrated Def inition
0 is for Function Modelling
1 is for Information Modelling - X is for Relational Database Modelling
they are all Standards published by NIST . I state that in my IDEF1X Notation document as well. .
11 Dec 10
What is your attitude to design databases by UML notation (diagram)? The rationale is that it is broadly (and ubiquitously) known and to minimize the number of notations to know for this and that purposes
First, I would ask, show me a UML "Relational Data Model" that has anywhere near the exposition of detail and subtlety of an IDEF1X model, and then we have something to discuss. Until then, it is idle speculation, pub talk by non-relational people, about what they do not know, from a framework of what they do know.
But I won't avoid the question.
Second, there is a big problem, with horrendous consequences, when people have a fixed mindset about an area of knowledge (Good Thing), but then they approach every other area that they do not know, with the same mindset, unwilling to learn the specialised skills. Those poor people have not read about Maslow's Hammer. The OO proponents are the biggest offenders. If I have answered this question once, I have answered it ten times, and I have only been here 3 weeks. They ask, as if they were the first person to find this problem, "how do I persist my object classes into a database", and they treat the database (forget Relational) like it is a rubbish bin.
Scott Ambler and Martin Fowler have a lot to answer for. First they write books on how to model objects the wrong way. Then they write books about how to fix the problem that they created. And this isn't just my opinion, many industry leaders make similar comments, they are famously written up in "Laugh or Cry" pages. Imagine "refactoring" a database. Only someone who has never read anything about databases would do that. A whole textbook on how to do that. Written by people who have never seen a real database.
Any serious, experienced modeller knows that if you design (model) the database correctly, it never needs refactoring.
The only "databases" that need refactoring are those created by people who treat the db like trash, after reading said "books", and they have explicit steps, on how to keep trashing it, over and over again. You wait, next year they will have "multifactoring".
What's the point? They never learned about the database; how to approach data transfers; how to model it. They just "modelled" it with a hammer. To someone like me, who fixes these problems in a way that they never come back, "How do I model my multi-level objects classes" tells me immediately they are clueless, they are "persisting" their Object models into the db, and have not even read enough to understand that the accurate question is "How do I model my Subtypes".
These are the issues on the surface. The flaws are fundamental and deeper, and affect everything they do re the database. Don't believe me, wait just a small amount of time after the "app" goes into production, and it hits the famous wall. They hit it so often, they even have an OO name for it: Object Relational Impedance Mismatch. Very scientific sounding name for plain stupidity. It hasn't occurred to them that if they designed the Relational database as a Relational database, and the OO app as an OO app, with a nice defined boundary, a transport layer between them, there would never be "Object Relational Impedance Mismatch".
The app (any language) and the db is like a good marriage. Each is completely different, they have their own needs, and they need each other. When they work together, it is a marriage made in heaven. As the great prophet Khalil Gibran wrote On Marriage:
Fill each other's cup but drink not from one cup ... For the pillars of the temple stand apart, And the oak tree and the cypress grow not in each other's shadow
When one partner treats the other like a slave, a receptacle, like they need not be recognised and understood, divorce and domestic violence are only a short distance away. Refactoring is merely a set of steps on how to make the right choice for your next mail order bride, how to train them to do the chores. Fixes the symptom for this month, but it does not go anywhere near the causative problem.
you can't "persist" object classes into a database. We have been writing ACID transactions for 30 years, not persistence objects. If you write persistence objects, you will have a single user app, with no concurrency, massively inefficient, full of broken transactions and data integrity problems.
you can't "design" databases like they are "object classes", because they aren't objects or classes. So stop wasting time, and learn how to design data in a multi-user location with some integrity. Or give the job to someone who knows how.
using OO notation or UML notation treats the database as a collection of objects, it only reinforces the Hammer, and makes sure it is the latest hardened steel with an imported Elm handle.
you can have a perfectly good marriage with a mail order bride. All it takes is a bit of recognition and respect.
that means, learn the terminology and the notation. Even if you gave the job to someone skilled, when they give you the finished diagram, you need to understand it. that is the boundary. You can't go "Eeeek! I've never seen that before".
you can't have some of the features of the database, but ignore the other fundamental requirements. I am certainly not saying that it is all-or-nothing, that too is immature. But you have to have a basic understanding of the person you are marrying; the better the understanding, the better the marriage.
you cannot open the database box, without addressing multiple online users; concurrency (and thus data currency); transactions; data and referential integrity; etc. These idiots (Fowler and Ambler, not the readers) are re-inventing the wheel, and they have not reached the wooden spoke stage yet; they have not recognised that the fat round thing that is bolted together is the impedance itself. Their "persistence objects" suffer all the problems (such as Lost Updates, avoiding low concurrency) that we eliminated 30 years ago
data that is modelled correctly does not change (it is easily extended, but that which exists, does not change). Apps come and go like ships. Object classes come and go with the developer. Therefore, if there were to be an order in the hierarchy (instead of an equal relationship), then the object should be modelled after the data.
note also, that well written apps (to Standard) are impervious to such changes; apps which take the "database is a slave" approach are brittle, and break at the slightest change; these are grossly sub-standard apps. But the OO people do not see that, they see "Impedance Mismatch".
if (a) the app and the database have reasonable independence, and (b) the boundaries are clear, each side can be changed and extended without affecting the other side.
alternately, if the app is truly the one-and-only main event, then to make it successful (avoid "refactoring" every year or so; write it correctly, once, so that it lasts), forget about databases, keep your objects on the C:\ drive, and persist them.
That's why, twenty years ago, some of us were saying, publishing articles, that Ambler and Fowler have it backwards. It is no wonder they keep crashing into things and refactoring themselves.
It is noteworthy that the secret behind Agile, is that it is fully Normalised. That is a 180 degree change for Ambler, his published works, so it is no surprise that it is something he cannot herald and declare openly.
And just to make sure it doesn't get lost in the wash. The Notation is on the surface, but it is telling, of what is inside. IDEF1X tells you about the Relational mindset of the person who modelled the database. UML Notation for a "relational database" tells you the mindset of the person who factored the data heap, and who expects to refactor it many, many times. Choose carefully.
I have more than a Hammer in my toolbox.
When I model data, I use IDEF1X
When I model functions, I use IDEF0 or SSADM (depending on the maturity of the users)
When I model objects, I use UML
I ride horses, shoot deer, fight fires, and chase women. Each activity has a different set of principles and rules, which I must follow in order for me to succeed reasonably. Imagine what life would be like if I mixed them up. Or if I could only shoot.
对于 ER 模型，我更喜欢 IEM 或 Barker 风格，因为我发现更多的人理解鱼尾纹表示法。如果您希望模型被比您自己更广泛的受众理解，那么使用公认的标准符号是有意义的。
至于数据库供应商工具，这取决于情况。我从来没有发现有必要使用任何特定的工具，除非客户已经在使用该工具。 Oracle 和 Sybase 有不错的图表工具。 Microsoft Visio 支持标准符号，尽管作为数据库设计工具它并不像许多其他工具那么强大。
我能想到的唯一真正糟糕的例子是 Microsoft SQL Server 工具集中内置的所谓设计工具。这只是一个笑话。完全无法用于任何严肃的目的，而且除了 Microsoft 出版物之外，我不认识任何人使用它。
For ER models I prefer the IEM or Barker style just because I find that more people understand the crow's feet notation. If you want a model to be understood by a wider audience than yourself then it makes sense to use a recognised standard notation.
As for database vendor tools, that depends. I've never found it essential to use any particular tool, except where a customer was already using one. Oracle and Sybase have decent diagram tools. Microsoft Visio supports the standard notations, although as a database design tool it isn't as powerful as many others.
The only really bad example I can think of is the so-called design tool built into the Microsoft SQL Server toolset. It's just a joke. Completely unusable for any serious purpose and I don't know anyone who uses it except in Microsoft publications.
I prefer to use a three stage approach: conceptual data modeling, logical data modeling, and physical data modeling. The use of fancy tools depends on the scope of the project.
The first stage is analysis, also known as requirements definition. The result of the first stage is a conceptual data model, and related diagrams. The first stage is data model agnostic.
I use ER modeling and ER diagrams. Attributes are discovered, and their domains are determined, if possible. Attributes are connected to subject matter entities and relationships among entities. Relationships are identified, but not implemented via foreign keys. Later on, in logical design, the relationships will actually be implemented.
Natural keys are identified, and evaluated as to whether they can be trusted.
The notation involves attributes, domains, entities and relationships.
The second stage is logical design. The result of the second stage is a logical data model, expressed in SQL terminology. I use SQL terminology like columns, rows, tables, and domains, although these are stand ins for attributes, tuples, relations, and domains. The logical model is specific to the relational data model, but is DBMS agnostic.
Unlike some practitioners, I use natural keys as PKs when they can be trusted. Otherwise, I invent surrogates.
The main difference is that foreign keys are now in the picture. Every entity gets a table. Some relationships are modeled by adding foreign keys to entity tables while other relationships get tables of their own. Many-to-many relationships are an example of the latter.
Issues like table composition and normalization are dealt with at this stage. Unlike some practitioners, I don't treat normalization as some kind of religion. I make design decisions in view of the consequences. However, departures from normalization have to have a specific justification.
if I were to design a non relational database, the second stage would look very different.
The third stage is physical design. This results in a physical data model. The physical data model starts with the logical data model, and adds features like indexes, tablespaces, stored procedures, and what have you. The physical design is DBMS specific, and takes into account volume, traffic, performance goals, and resources available.
The physical data model is a blueprint for database construction.
发布评论
评论（3）
Extended 11 Dec 2010
这个问题是什么意思？
在回答“符号”问题之前，这是表面上可见的小问题，我们需要了解支撑它的问题，这些问题导致了表面的问题问题。否则，与问题的相关性就会降低到个人偏好；某些产品或其他产品提供什么，是否免费等。
标准
我认为读者没有理由认为用公共资金为公众建造的桥梁（而不是在私人土地上建造供个人使用的业余爱好桥梁）需要有标准，以确保它们不倒塌；它们可以承载所声明的交通，并且人们在使用它们时不会死亡。预期的标准首先由高度认可和认可的工程专家提出，并由同行大量实践和测试，最终获得标准地位，并由政府标准机构宣布为标准。然后，当局只需确定所有供应商必须遵守的标准，以便为政府提供桥梁。
与不合规的工程公司进行讨论是浪费时间，因为他们的不合标准的产品的哪些内容或为何值得评估。或者查看缺少特定信息（标准要求）的图表。或者与自称桥梁建造商但工资单上没有土木工程师的公司交谈。
标准标准化
标准的另一个重要方面是不重复。桥梁建设标准只需参考桥梁上所有接线的电气标准即可，不重复内容。标准已标准化。这使得每个标准都可以进步和改变（例如，由于新的建筑材料的出现，在适当的情况下），而不影响其他标准或其合规性。
同样，标准也不竞争。如果遵守桥梁建设标准，就不会有违反通信标准的危险。
标准涉及更高的原则
因此，标准是每一个真正提供质量和性能的供应商都热切遵守的更高原则。其他问题包括从不情愿遵守到不知道存在适用标准。
标准不是符号
第三，标准不仅仅是图表必须遵守的一组符号和符号。不合格和缺乏经验的桥梁建造者可能会说是的，因为他们对建造完美桥梁所需的整套知识的理解水平较低，但事实并非如此。标准始终是一种方法或一组明确的步骤，为流程规定了这些步骤，如果遵守该标准，则会产生需要在每个步骤中逐级做出的决策，以便每个决策都可以基于先前的决策已经得到证实，可以信赖。一个简单的图表会经历规定的符合标准的阶段或阶段，并逐渐添加复杂性和符号，以便最终的图表符合标准。
标准完整
第四个问题与确保图表中传达的信息完整且明确有关。该标准确保所需信息的完整性。该方法的运用意味着歧义已被正式识别和解决。次标准图表不包括基本标准信息的要求，它们不完整且包含歧义。
标准很容易
除了达到一定质量水平的信心之外，通过标准方法实际上更容易、更快。对于未提出投诉的公司来说，仅仅通过向他们提供标准符号来改造他们的图表是荒谬的。对于任何了解标准的人来说，缺乏规定的流程都是可见的，并且图表将发生冲突（组件缺乏集成）。
负责任、有意识的客户（政府部门、飞机制造商……预计在未来十年内存在的公司）有合理的期望，即从供应商处购买的软件将具有一定的质量；易于增强和扩展；表现良好；将轻松与其他软件集成； IT
缺乏 IT 标准
行业的问题是，与汽车制造或桥梁建筑行业不同，自从 IT 行业在过去 30 年中呈爆炸式增长以来，我们已经充斥着以下供应商：
这一直是许多研究和出版物，这不仅仅是我的专业意见，这要归功于那些辛勤工作筛选并确定具体问题的学者。
因此，就整个IT提供商、IT公司以及非IT公司的IT员工而言，质量意识、提供质量所需的标准及其重要性都比30年前低得多。这是一种“构建后忘记”的心态；如果它不起作用，就扔掉它并建造另一个。但对于城市的高端、有责任心的顾客来说，这是不可接受的。
标准不是单一供应商
根据定义，标准是由多个供应商在国际层面达成的。
该行业的一个巨大问题是，尽管有优秀的供应商提供了用于真实建模的良好工具（生成符合标准的图表），但我们也有供应商提供各种荒谬的图片和不合规的图表。这使得 IT 人员能够制作出好看但完全没有意义的图表。关键是，这些可怕的小工具实际上给了人们信心，他们已经建立了一座良好的桥梁，一个良好的数据库。首先，他们创建一堆电子表格，将其加载到一个称为“数据库”的容器中，软件帮助他们认为他们现在有了一个“数据库”；然后他们使用工具对“数据库”进行逆向工程以生成“数据模型”。这给了他们虚假的信心；他们不知道自己有一桶鱼的有趣图片，如果有人指出这一点，他们会感到被冒犯。坚持使用通过声明和认证符合标准的工具，并丢弃那些不符合标准的工具。
单一供应商的非标准工具可能会给人一种孤立的舒适感和轻松感，以及一种错误的自信感。但如果想要获得传达所有必需信息的图表，则不能使用它们；通过接受合格的同行而获得的信心；从一组规定的步骤中得出的质量；相信人们不必继续修改模型。
约定不是标准
在有人指出这些可怕的工具是“事实上的标准”之前，不，它们不是，它们是通用约定，没有提及标准，我们不应该混淆两个使用“标准”一词来引用它们。起床煮咖啡的方式是一种惯例，可能很常见，但它不是“标准”。您的共同供应商出于商业利益，可能会让您商业化，让您相信只有一台“标准”咖啡机和一种“标准”咖啡豆，但这与咖啡机制造商必须遵守的标准无关，或进口到该国的咖啡豆标准。
微软臭名昭著的错误引用，将汽车行业的进步与微软的“进步”进行了比较，汽车行业对此做出了公开回应，理所当然的愤慨，并抹去了比尔·盖茨脸上的笑容。 Sun Microsystems 也做出了著名的回应，但我怀疑 MS 圈子是否知道这一点。请注意，MS 的可信度是通过绝对数量来获得的：在 MS 爱好者之间提供和交换不断变化的“信息”的互联网站点的数量。他们脱离了真正的资格和标准，并错误地认为单一供应商惯例和部分性能，使用漂亮的图片，实际上构成了“软件”。
标准并不昂贵
这并不意味着您必须购买昂贵的工具。对于小型项目，使用简单的绘图工具来绘制图表是完全可以接受的，因为对标准的遵守是在头骨中，在规定的方法中，而不是在工具中，因此有可能建立一个合格的、有标准意识的人。人员可以使用几乎任何工具生成符合标准的图纸（适用于小型项目）。请注意，那些歪曲自己的可怕工具不提供标准符号；绝大多数的“数据模型”和“实体关系图”都严重不合标准。
关系数据库标准
以下内容的标准或精确定义或具体指南已经存在了 30 多年。按渐进顺序，每个包含前一个：
标准化（对于任何数据库）
（标准不是必需的，它是一个工程原理；在许多学科中都是通用的；对于合格的人来说是一个简单的过程；并且很容易识别出缺乏标准。）
关系数据库
关系模型：EF Codd & CJ日期
著名的关系合规十二条规则
EF科德
关系数据建模
IDEF1X; 20世纪80年代； NIST 标准 1993 年 FIPS 184
许多供应商已按照规定实践这些方法，从而符合标准长达 30 年。
注意，只有一种关系数据建模标准，不存在冲突。
请注意，该符号只是您在表面上看到的结果，但它确实表明其他符号中缺少信息，并且未遵循基本方法。
请注意，标准化早于关系模型，并且被视为给定的；这就是为什么 RM 没有具体引用规范化作为原则，而仅根据关系数据库的要求识别范式。
如果您真正有资格成为关系数据库建模者，您将非常熟悉前三个；如果您是符合标准的关系数据库建模者，您将对第四种非常熟悉。同样，您不能合理地期望仅通过学习 IDEF1X Notation，你需要实际学习和实践方法论，但学习 Notation 可能是一个合理的入门。
[某些]要求[遵守]标准
有意识、负责任的客户要求遵守这些标准。
然后是其他领域，包括不知情的客户和不知情的供应商，以及介于两者之间的一切。
哪种表示法？
对于大多数了解标准的从业者来说，没有必要讨论“使用哪种表示法”，因为只有一个标准。当没有其他标准时，为什么我要使用其他符号来绘制图表（在大型项目中使用昂贵的工具，或者使用简单的绘图工具来回答 Stack Overflow 上的问题）？当我可以轻松传达标准信息时，为什么我传达的信息少于标准信息？当我知道使用该标准可以提供数据模型正确性的正式信心并且经得起审查（而不是被大多数粗略的质疑所刺穿的想象中的信心）时，为什么我要避免使用该标准？
如果某个合格的、公认的组织提出了一种新的方法（相信我，他们一直这样做），我们就会对此进行调查。如果当该方法论获得学术界同行的认可和认可时，我们将认真对待它，尝试它，并熟练掌握它。如果国际标准机构（而不是单一供应商）宣布该标准为标准，我们将提供该标准。在那之前，我们将完全遵守现有的标准。
未来符号和符号约定
过去 20 年中的数百个单一供应商产品不值得花时间进行调查。因此，单一供应商约定，无论是否标记为“标准”，都不值得花费时间进行调查。事实上，由于该标准已经存在，并且早于单一供应商的出现，因此任何单一供应商的产品都将隐含声明他们无法遵守该标准 ，并且他们提供反标准作为替代。
对评论的回应
反驳业余爱好者关于某些垃圾是“标准”的指控的最简单方法是索要其 ISO/ANSI/IEC/NIST/etc 发布数据。根据上述（4），IDEF1X是已发布的标准，易于查找。
MS 以发布反标准并称其为“标准”而闻名。正确的术语是“约定”。维基百科本周可能会将某些 MS 表示法称为标准，但我已经指出维基百科不是可靠的来源。请记住，根据定义，单一供应商产品并不是标准。
IDEF1X 也是一个业务流程建模标准
不完全是。 IDEF1X 链接会将您带到最负责任的组织宣传它并教育人们。如果您检查该页面上的选项卡，您会发现几个标准。标准的强大功能（美丽？）之一是它们是集成的：
- X 代表关系数据库建模
.
我在我的IDEF1X Notation中声明 文档也是如此。
。
2010-12-11
首先，我会问，向我展示一个 UML“关系数据模型”，它具有接近阐述了 IDEF1X 模型的细节和微妙之处，然后我们有一些东西要讨论。在那之前，这只是无关系的人从他们所知道的框架中谈论他们不知道的事情的无意义的猜测和酒吧谈话。
但我不会回避这个问题。
其次，存在一个大问题，当人们对某个知识领域（好东西）抱有固定心态时，就会出现可怕的后果，但随后他们以同样的心态进入他们不知道的其他所有领域，不愿意学习该知识领域。专业技能。那些穷人没有读过马斯洛之锤 。面向对象的支持者是最大的罪犯。如果我回答过这个问题一次，那么我已经回答了十次了，而我才来这里三个星期。他们问，就好像他们是第一个发现这个问题的人一样，“我如何将我的对象类持久化到数据库中”，并且他们将数据库（忘记关系型）视为垃圾箱。
斯科特·安布勒和马丁·福勒有很多事情要负责。首先，他们写了关于如何以错误的方式建模对象的书籍。然后他们写了一些关于如何解决他们造成的问题的书。这不仅仅是我的观点，许多行业领导者都发表了类似的评论，他们被著名地写在“笑或哭”页面上。想象一下“重构”数据库。只有从未读过任何有关数据库的内容的人才会这样做。一本关于如何做到这一点的完整教科书。由从未见过真正数据库的人编写。
任何认真的、经验丰富的建模者都知道，如果您正确地设计（建模）数据库，它永远不需要重构。
唯一需要重构的“数据库”是由那些将数据库视为垃圾的人在阅读上述“书籍”后创建的，并且他们有明确的步骤，关于如何一遍又一遍地继续垃圾处理。你等着吧，明年他们就会有“多重因素”。
有什么意义？他们从未了解过数据库；如何进行数据传输；如何对其进行建模。他们只是用锤子“建模”它。对于像我这样以永远不会回来的方式解决这些问题的人来说，“我如何建模我的多级对象类”立即告诉我他们一无所知，他们正在将他们的对象模型“持久化”到数据库中，并且甚至没有阅读足够的内容来理解准确的问题是“如何为我的子类型建模”。
这些都是表面上的问题。这些缺陷是根本性的、更深层次的，会影响他们对数据库所做的一切。不相信我，在“应用程序”投入生产后只等了一小会儿，它就撞上了著名的墙。他们经常遇到这个问题，甚至给它起了一个面向对象的名称：对象关系阻抗不匹配。听起来非常科学的名字，代表着愚蠢的行为。他们没有想到，如果他们将关系数据库设计为关系数据库，将 OO 应用程序设计为 OO 应用程序，并在它们之间有一个明确定义的边界和传输层，则永远不会出现“对象关系阻抗不匹配” 。
应用程序（任何语言）和数据库就像一对美好的婚姻。每个人都是完全不同的，他们有自己的需求，并且彼此需要。当他们一起工作时，这就是天作之合。正如伟大的先知纪伯伦在《论婚姻》中所写的那样：
为彼此斟满杯子，但不要只喝一杯......
因为圣殿的柱子是分开的，
而橡树和柏树并不是在彼此的阴影下生长的。
当一方把对方当作奴隶、容器，不需要被认可和理解时，离婚和家庭暴力就离我们不远了。重构只是关于如何为您的下一个邮购新娘做出正确选择，以及如何训练她们做家务的一组步骤。修复了本月的症状，但并没有解决根本问题。
您无法将对象类“持久化”到数据库中。 30 年来我们一直在编写 ACID 事务，而不是持久对象。如果您编写持久性对象，您将拥有一个单一用户应用程序，没有并发性，效率极低，充满了损坏的事务和数据完整性问题。
您不能像“对象类”一样“设计”数据库，因为它们不是对象或类。因此，不要再浪费时间了，学习如何在多用户位置以一定的完整性设计数据。或者将这份工作交给懂得如何做的人。
使用 OO 表示法或 UML 表示法将数据库视为对象的集合，它仅加固锤子，并确保它是带有进口 Elm 手柄的最新硬化钢。
您可以与邮购新娘拥有完美的婚姻。所需要的只是一点认可和尊重。
这意味着，学习术语和符号。即使你把这项工作交给了熟练的人，当他们给你完成的图表时，你也需要理解它。那就是边界。你不能说“哎呀！我以前从没见过这个”。
您不能拥有数据库的某些功能，但忽略其他基本要求。我当然不是说这是全有或全无，这也是不成熟的。但你必须对你的结婚对象有一个基本的了解；理解越好，婚姻就越好。
如果不寻址多个在线用户，则无法打开数据库框；并发性（以及数据货币）；交易；数据和引用完整性；这些白痴（福勒和安布勒，不是读者）正在重新发明轮子，他们还没有达到木辐阶段；他们没有认识到用螺栓固定在一起的那个胖圆的东西就是阻抗本身。他们的“持久性对象”遭受了我们 30 年前消除的所有问题（例如丢失更新、避免低并发）
正确建模的数据不会改变（它很容易扩展，但存在的数据不会改变） ）。应用程序像船一样来来去去。对象类随着开发人员的变化而变化。因此，如果层次结构中有顺序（而不是平等关系），则应该在数据之后对对象进行建模。
另请注意，编写良好的应用程序（标准）不会受到此类更改的影响；采用“数据库是奴隶”方法的应用程序很脆弱，稍有变化就会崩溃；这些都是严重不合标准的应用程序。但面向对象的人看不到这一点，他们看到的是“阻抗不匹配”。
如果 (a) 应用程序和数据库具有合理的独立性，并且 (b) 边界清晰，则每一侧都可以更改和扩展而不影响另一侧。
或者，如果应用程序确实是唯一的主要事件，那么为了使其成功（避免每年左右“重构”；正确编写一次，以便它持续），忘记关于数据库，请将对象保存在 C:\ 驱动器上，并持久保存它们。
这就是为什么，二十年前，我们中的一些人发表文章说，安布勒和福勒搞错了。难怪他们不断地撞上东西并重构自己。
值得注意的是，敏捷背后的秘密在于它是完全规范化的。对于安布勒出版的作品来说，这是一个 180 度的转变，因此他不能公开宣布和宣布这一点也就不足为奇了。
只是为了确保它不会在洗涤过程中丢失。符号位于表面，但它讲述了内部的内容。 IDEF1X 告诉您数据库建模者的关系思维方式。 “关系数据库”的 UML 表示法告诉您分解数据堆并希望对其进行多次重构的人的心态。仔细选择。
我的工具箱里不止有一把锤子。
我骑马、射鹿、救火、追女人。每项活动都有一套不同的原则和规则，我必须遵循这些原则和规则才能合理地取得成功。想象一下，如果我把它们混合在一起，生活会是什么样子。或者如果我只能射击。
Extended 11 Dec 10
What does the question mean ?
Before answering the "notation" question, which is the small visible issue on the surface, we need to understand the issues that underpin it, which lead to the surface issues. Otherwise the relevance to the question is reduced to personal preferences; what some product or other provides, whether it is free, etc.
Standards
I assume that the reader has no argument that bridges built for the public out of the public purse (as opposed to hobby bridges built on private land for personal use) need to have standards, in order to ensure that they do not fall over; that they can carry the declared traffic, and that people will not die while using them. The intended standards are first presented by highly acknowledged and recognised engineering experts, and heavily practised and tested by their peers, eventually attaining the status of a Standard, and being declared as such by government standards bodies. The authorities then simply identify the standards that all suppliers must conform to, in order to supply bridges to the government.
It is a waste of time to engage is discussion with non-compliant engineering companies, as what or why their sub-standard offering is worthy of evaluation. Or to look at diagrams that have specific information (demanded by the Standard) missing from them. Or to talk to companies presenting themselves as bridge builders, but who have no civil engineers on the payroll.
Standards are Normalised
Another important aspect of Standards, is that there is no repetition. The bridge building standard only has to refer to the electrical standard for all wiring on the bridge, it does not repeat the content. Standards are Normalised. This allows each Standard to progress and change (eg. as appropriate, due to new building materials becoming available), without affecting other standards or their compliance.
Likewise, Standards do not compete. If one complies with the bridge building standard, there is no danger that one has broken the communications standard.
Standards relate to Higher Principles
Standards are thus the higher principles that every supplier who genuinely supplies quality and performance, will eagerly comply with. And the others will range from reluctant compliance all the way through to ignorance that an applicable standard exists.
Standards are Not a Notation
Third, the Standard is not merely a set of symbols and notations that the diagram must comply with. The unqualified and inexperienced bridge builders may say it is, because of their low level of understanding of the entire set of knowledge required to build faultless bridges, but no. The Standard is always a methodology or set of explicit steps, which are prescribed for the process, which if adhered to, produce the decisions that need to be made at each step, in a progression, so that each decision can be based on previous decisions that have been confirmed, and that can be relied upon. A simple diagram progresses through prescribed standard-compliant stages or phases, with complexity and notations being progressively added, such that the final diagram is compliant.
Standards are Complete
The fourth issue has to do with ensuring that the information conveyed in a diagram is complete and unambiguous. The Standard ensures that the information required is complete. The exercise of the methodology means that ambiguities have been formally identified and resolved. Sub-standard diagrams do not include that requirement of essential Standard information, they are incomplete and contain ambiguities.
Standards are Easy
In addition to the confidence of achieving a certain level of quality, it is actually easier and faster to go through the standard methodology. It is absurd for the non-complaint companies to retro-fit their diagrams by merely supplying standard notation to them. The absence of the prescribed process is visible to any standard-aware person, and the diagram will conflicted (the components s lacking integration).
Responsible, aware customers (government departments, aircraft manufacturers ... companies that expect to be around in the next decade) have reasonable expectations that the software it purchases from suppliers will be of a certain quality; easy to enhance and extend; perform well; will integrate easily with other software; etc.
Lack of Standards in IT
The problem with the IT industry is, unlike the car manufacturing or bridge building industries, since it has exploded in the last 30 years, we have been flooded with providers who are:
This has been the subject of much research and publications, it is not merely my professional opinion, the credit goes to the academics who did the hard work to sift through and identify exactly what the specific issues are.
So in terms of the whole population of IT providers, IT companies as well as IT employees in non-IT companies, the awareness of quality, of the standards required to provide quality, and their importance, is much lower than it was 30 years ago. It is a 'build and forget' mentality; if it doesn't work, throw it out and build another one. But for the big end of town, the responsible aware customers, that is not acceptable.
Standards are Not Single-Vendor
By definition, Standards are arrived at by multiple vendors, at the international level.
One huge problem in the industry is, in spite of having good vendors who supply good tools for real modelling (the resulting diagrams which comply with Standards), we also have vendors who supply a full range of absurd pictures and non-compliant diagrams. This allows IT people to produce good-looking but completely meaningless diagrams. The point is, these horrible little tools actually give people confidence, that they have built a good bridge, a good database. First they create a bunch of spreadsheets, which they load into a container called a "database" and the software helps them think that they now have a "database"; then they use a tool and reverse-engineer the "database" to produce a "data model". It gives them false confidence; they are unaware that they have a funny picture of a bucket of fish, and they feel offended if anyone points that out. Stick with the tools that are standard-compliant by declaration and certification, and toss those that aren't.
The single-vendor non-standard tools may give one comfort and ease, and a false sense of confidence, in isolation. But they cannot be used if one wants to achieve diagrams that convey all required info; confidence that is gained by acceptance of qualified peers; quality that is derived from a prescribed set of steps; confidence that one does not have to keep on reworking the model.
Conventions are Not Standards
And before anyone points out the the horrible tools are "de facto standards", no they aren't, they are common conventions, with no reference to Standards, and we should not confuse the two by using the word "standard" in reference to them. The way one gets out of bed and makes coffee is a convention, possibly very common, but it is not a "standard". Your common vendor, in their commercial interest, may have commercialised you into believing that there is only one "standard" coffee machine and one "standard" coffee bean, but that bears no relation to the Standards to which the coffee machine manufacturer must comply, or the Standard of coffee bean imported into the country.
There is the mis-quotation that MS is infamous for, comparing the progress of car industry to the "progress" of Microsoft, which the car industry responded to publicly, with justified indignation, and wiped the grin off Bill Gate's face. Sun Microsystems also responded, famously, but I doubt that is known in MS circles. Note that MS credibility is gained by sheer volume: the number of internet sites providing and exchanging ever-changing "information" among MS devotees. They are isolated from genuine qualifications and Standards, and falsely believe that single-vendor conventions, and partial performance, using nice-looking pictures, actually comprise "software".
Standards are Not Expensive
That does not mean you have to buy expensive tools. For small projects, it is quite acceptable to draw diagrams using simple drawing tools, because the compliance-to-standards is in the cranium, in the prescribed methodology, not in the tool, and therefore it is possible for a qualified, standards-aware person to produce standard-compliant drawings (for small projects) with any almost tool. And note that those horrible tools which misrepresent themselves do not provide the standard notation; the vast majority of "data models" and "entity relation diagrams" out there, are grossly sub-standard.
Standards re Relational Databases
Standards or precise definitions or specific guidelines, for the following have existed for over 30 years. In progressive order, each containing the previous:
Normalisation (for any Database)
(a Standard is not required, it is an engineering principle; common across many disciplines; a simple process for those qualified; and absence of it is easily identified.)
Relational Databases
The Relational Model: E F Codd & C J Date
The famous Twelve Rules of Relational Compliance
E F Codd
Relational Data Modelling
IDEF1X; 1980's; NIST Standard FIPS 184 of 1993
There are many suppliers who have practised these methodologies, as prescribed, thereby conforming to the Standards, for up to 30 years.
Note, there is only one Relational Data Modelling Standard, there is no conflict.
Note, the notation is just what you see on the surface, the result, however it does identify that other notations have info missing from them, and the underlying methodology was not followed.
Note well, that Normalisation pre-dated the Relational Model, and was taken as given; that is why the RM does not have specific references to Normalisation as a principle, and only identifies the Normal Forms, in terms of the requirement for Relational Databases.
If you are genuinely qualified as a Relational Database Modeller, you will be intimately familiar with the first three; if you are a standard-compliant Relational Database Modeller, you will be intimately familiar with the fourth. Again, you cannot reasonably expect to comply with the Standard merely by learning the IDEF1X Notation, you need to actually learn and practise the methodology, but learning the Notation may be a reasonable introduction.
[Compliance to] Standard is Demanded [by Some]
There are aware, responsible customers, who demand compliance with these Standards.
And then there is the rest of field, both the unaware customers and the unaware suppliers, and everything in-between.
Which Notation ?
For most standards-aware practitioners, there is no need to discuss "which notation to use", given that there is only one Standard. Why would I draw a diagram (using either an expensive tool in a large project, or a simple drawing tool to answer a question on Stack Overflow), using some other notation when there is no other standard ? Why would I convey less than the Standard information, when I can convey the Standard info just as easily ? Why would I avoid using the Standard, when I know that using the Standard provides the formal confidence that the Data Model is correct, and will stand up to scrutiny (as opposed to the imagined confidence that is punctured by most cursory questioning) ?
If, and when, some qualified, recognised organisation comes up with a new methodology (and believe me, they do, all the time), we look into it. If and when the methodology achieves academic peer recognition and acknowledgement, we will take it seriously, try it out, become adept with it. If and when it is declared a Standard by the international standards bodies (as opposed to single vendor), we will provide it. Until then, we provide the full compliance to Standards that do exist.
Future Notations & Conventions
The couple of hundred single-vendor offerings in the last 20 years were not worth the time spent in investigation. Therefore single-vendor conventions, be they labelled "standards" or not, are not worth the time spent in investigation. In fact, since the Standard exists, and pre-dated the advent of the single vendor, any single-vendor offering would be an implicit declaration that they cannot comply with the Standard, and they are offering an anti-standard as a substitution.
Responses to Comments
The easiest way to refute an amateur's allegation that some rubbish is a "standard" is to ask for its ISO/ANSI/IEC/NIST/etc publication data. As per (4) above IDEF1X is a published Standard, easy to look up.
MS is famous for publishing anti-standards, and calling them "standards". The correct term is "convention". Wikipedia might call some MS notation a standard this week, but I've already noted that Wikipedia is not a reliable source. Remember, a single-vendor offering is, by definition, not a standard.
IDEF1X is also a business process modelling standard
Not quite. The IDEF1X link will take you to the organisation that is most responsible for publicising it and educating people about it. If you check the tabs on that page, you will find several standards. One of the great powers (beauties?) of Standards is that they are integrated:
- X is for Relational Database Modelling
.
I state that in my IDEF1X Notation document as well.
.
11 Dec 10
First, I would ask, show me a UML "Relational Data Model" that has anywhere near the exposition of detail and subtlety of an IDEF1X model, and then we have something to discuss. Until then, it is idle speculation, pub talk by non-relational people, about what they do not know, from a framework of what they do know.
But I won't avoid the question.
Second, there is a big problem, with horrendous consequences, when people have a fixed mindset about an area of knowledge (Good Thing), but then they approach every other area that they do not know, with the same mindset, unwilling to learn the specialised skills. Those poor people have not read about Maslow's Hammer. The OO proponents are the biggest offenders. If I have answered this question once, I have answered it ten times, and I have only been here 3 weeks. They ask, as if they were the first person to find this problem, "how do I persist my object classes into a database", and they treat the database (forget Relational) like it is a rubbish bin.
Scott Ambler and Martin Fowler have a lot to answer for. First they write books on how to model objects the wrong way. Then they write books about how to fix the problem that they created. And this isn't just my opinion, many industry leaders make similar comments, they are famously written up in "Laugh or Cry" pages. Imagine "refactoring" a database. Only someone who has never read anything about databases would do that. A whole textbook on how to do that. Written by people who have never seen a real database.
Any serious, experienced modeller knows that if you design (model) the database correctly, it never needs refactoring.
The only "databases" that need refactoring are those created by people who treat the db like trash, after reading said "books", and they have explicit steps, on how to keep trashing it, over and over again. You wait, next year they will have "multifactoring".
What's the point? They never learned about the database; how to approach data transfers; how to model it. They just "modelled" it with a hammer. To someone like me, who fixes these problems in a way that they never come back, "How do I model my multi-level objects classes" tells me immediately they are clueless, they are "persisting" their Object models into the db, and have not even read enough to understand that the accurate question is "How do I model my Subtypes".
These are the issues on the surface. The flaws are fundamental and deeper, and affect everything they do re the database. Don't believe me, wait just a small amount of time after the "app" goes into production, and it hits the famous wall. They hit it so often, they even have an OO name for it: Object Relational Impedance Mismatch. Very scientific sounding name for plain stupidity. It hasn't occurred to them that if they designed the Relational database as a Relational database, and the OO app as an OO app, with a nice defined boundary, a transport layer between them, there would never be "Object Relational Impedance Mismatch".
The app (any language) and the db is like a good marriage. Each is completely different, they have their own needs, and they need each other. When they work together, it is a marriage made in heaven. As the great prophet Khalil Gibran wrote On Marriage:
Fill each other's cup but drink not from one cup ...
For the pillars of the temple stand apart,
And the oak tree and the cypress grow not in each other's shadow
When one partner treats the other like a slave, a receptacle, like they need not be recognised and understood, divorce and domestic violence are only a short distance away. Refactoring is merely a set of steps on how to make the right choice for your next mail order bride, how to train them to do the chores. Fixes the symptom for this month, but it does not go anywhere near the causative problem.
you can't "persist" object classes into a database. We have been writing ACID transactions for 30 years, not persistence objects. If you write persistence objects, you will have a single user app, with no concurrency, massively inefficient, full of broken transactions and data integrity problems.
you can't "design" databases like they are "object classes", because they aren't objects or classes. So stop wasting time, and learn how to design data in a multi-user location with some integrity. Or give the job to someone who knows how.
using OO notation or UML notation treats the database as a collection of objects, it only reinforces the Hammer, and makes sure it is the latest hardened steel with an imported Elm handle.
you can have a perfectly good marriage with a mail order bride. All it takes is a bit of recognition and respect.
that means, learn the terminology and the notation. Even if you gave the job to someone skilled, when they give you the finished diagram, you need to understand it. that is the boundary. You can't go "Eeeek! I've never seen that before".
you can't have some of the features of the database, but ignore the other fundamental requirements. I am certainly not saying that it is all-or-nothing, that too is immature. But you have to have a basic understanding of the person you are marrying; the better the understanding, the better the marriage.
you cannot open the database box, without addressing multiple online users; concurrency (and thus data currency); transactions; data and referential integrity; etc. These idiots (Fowler and Ambler, not the readers) are re-inventing the wheel, and they have not reached the wooden spoke stage yet; they have not recognised that the fat round thing that is bolted together is the impedance itself. Their "persistence objects" suffer all the problems (such as Lost Updates, avoiding low concurrency) that we eliminated 30 years ago
data that is modelled correctly does not change (it is easily extended, but that which exists, does not change). Apps come and go like ships. Object classes come and go with the developer. Therefore, if there were to be an order in the hierarchy (instead of an equal relationship), then the object should be modelled after the data.
note also, that well written apps (to Standard) are impervious to such changes; apps which take the "database is a slave" approach are brittle, and break at the slightest change; these are grossly sub-standard apps. But the OO people do not see that, they see "Impedance Mismatch".
if (a) the app and the database have reasonable independence, and (b) the boundaries are clear, each side can be changed and extended without affecting the other side.
alternately, if the app is truly the one-and-only main event, then to make it successful (avoid "refactoring" every year or so; write it correctly, once, so that it lasts), forget about databases, keep your objects on the C:\ drive, and persist them.
That's why, twenty years ago, some of us were saying, publishing articles, that Ambler and Fowler have it backwards. It is no wonder they keep crashing into things and refactoring themselves.
It is noteworthy that the secret behind Agile, is that it is fully Normalised. That is a 180 degree change for Ambler, his published works, so it is no surprise that it is something he cannot herald and declare openly.
And just to make sure it doesn't get lost in the wash. The Notation is on the surface, but it is telling, of what is inside. IDEF1X tells you about the Relational mindset of the person who modelled the database. UML Notation for a "relational database" tells you the mindset of the person who factored the data heap, and who expects to refactor it many, many times. Choose carefully.
I have more than a Hammer in my toolbox.
I ride horses, shoot deer, fight fires, and chase women. Each activity has a different set of principles and rules, which I must follow in order for me to succeed reasonably. Imagine what life would be like if I mixed them up. Or if I could only shoot.
对于 ER 模型，我更喜欢 IEM 或 Barker 风格，因为我发现更多的人理解鱼尾纹表示法。如果您希望模型被比您自己更广泛的受众理解，那么使用公认的标准符号是有意义的。
至于数据库供应商工具，这取决于情况。我从来没有发现有必要使用任何特定的工具，除非客户已经在使用该工具。 Oracle 和 Sybase 有不错的图表工具。 Microsoft Visio 支持标准符号，尽管作为数据库设计工具它并不像许多其他工具那么强大。
我能想到的唯一真正糟糕的例子是 Microsoft SQL Server 工具集中内置的所谓设计工具。这只是一个笑话。完全无法用于任何严肃的目的，而且除了 Microsoft 出版物之外，我不认识任何人使用它。
For ER models I prefer the IEM or Barker style just because I find that more people understand the crow's feet notation. If you want a model to be understood by a wider audience than yourself then it makes sense to use a recognised standard notation.
As for database vendor tools, that depends. I've never found it essential to use any particular tool, except where a customer was already using one. Oracle and Sybase have decent diagram tools. Microsoft Visio supports the standard notations, although as a database design tool it isn't as powerful as many others.
The only really bad example I can think of is the so-called design tool built into the Microsoft SQL Server toolset. It's just a joke. Completely unusable for any serious purpose and I don't know anyone who uses it except in Microsoft publications.
我更喜欢使用三阶段方法：概念数据建模、逻辑数据建模和物理数据建模。花哨工具的使用取决于项目的范围。
第一阶段是分析，也称为需求定义。第一阶段的结果是概念数据模型和相关图表。第一阶段与数据模型无关。
我使用 ER 建模和 ER 图。如果可能的话，会发现属性并确定它们的域。属性与主题实体和实体之间的关系相关。关系被识别，但不是通过外键实现的。稍后，在逻辑设计中，这些关系将被实际实现。
识别自然密钥，并评估它们是否可信。
符号涉及属性、域、实体和关系。
第二阶段是逻辑设计。第二阶段的结果是一个逻辑数据模型，用 SQL 术语表达。我使用列、行、表和域等 SQL 术语，尽管这些术语代表属性、元组、关系和域。
逻辑模型特定于关系数据模型，但与 DBMS 无关。
与一些从业者不同，我在可以信任的情况下使用自然密钥作为 PK。否则，我就发明代理人。
主要区别在于外键现在出现在图片中。每个实体都有一个表。某些关系是通过向实体表添加外键来建模的，而其他关系则拥有自己的表。多对多关系是后者的一个例子。
表组成和规范化等问题在此阶段处理。与某些实践者不同，我并不将正常化视为某种宗教。我根据后果做出设计决策。然而，偏离正常化必须有具体的理由。
如果我要设计一个非关系数据库，第二阶段看起来会非常不同。
第三阶段是物理设计。这产生了物理数据模型。物理数据模型从逻辑数据模型开始，并添加索引、表空间、存储过程等功能。物理设计是特定于 DBMS 的，并考虑了容量、流量、性能目标和可用资源。
物理数据模型是数据库构建的蓝图。
I prefer to use a three stage approach: conceptual data modeling, logical data modeling, and physical data modeling. The use of fancy tools depends on the scope of the project.
The first stage is analysis, also known as requirements definition. The result of the first stage is a conceptual data model, and related diagrams. The first stage is data model agnostic.
I use ER modeling and ER diagrams. Attributes are discovered, and their domains are determined, if possible. Attributes are connected to subject matter entities and relationships among entities. Relationships are identified, but not implemented via foreign keys. Later on, in logical design, the relationships will actually be implemented.
Natural keys are identified, and evaluated as to whether they can be trusted.
The notation involves attributes, domains, entities and relationships.
The second stage is logical design. The result of the second stage is a logical data model, expressed in SQL terminology. I use SQL terminology like columns, rows, tables, and domains, although these are stand ins for attributes, tuples, relations, and domains.
The logical model is specific to the relational data model, but is DBMS agnostic.
Unlike some practitioners, I use natural keys as PKs when they can be trusted. Otherwise, I invent surrogates.
The main difference is that foreign keys are now in the picture. Every entity gets a table. Some relationships are modeled by adding foreign keys to entity tables while other relationships get tables of their own. Many-to-many relationships are an example of the latter.
Issues like table composition and normalization are dealt with at this stage. Unlike some practitioners, I don't treat normalization as some kind of religion. I make design decisions in view of the consequences. However, departures from normalization have to have a specific justification.
if I were to design a non relational database, the second stage would look very different.
The third stage is physical design. This results in a physical data model. The physical data model starts with the logical data model, and adds features like indexes, tablespaces, stored procedures, and what have you. The physical design is DBMS specific, and takes into account volume, traffic, performance goals, and resources available.
The physical data model is a blueprint for database construction.