动态数据库设计？
我收到了医院用来收集患者信息的表格的硬拷贝！该表格分为几个部分，每个部分都有很多是/否复选框。
例如，其中一个部分是“历史记录”部分，其中包含 20 多个不相关的是/否字段：
吸烟者（是或否）
糖尿病（是或否）
慢性肺病（是或否） 。 。 。 。 。
另一部分是“压力测试数据”部分，其中包含以下问题：
标准测试（是/否），如果是，结果是什么（阴性或阳性）， 如果是肯定的（程度是多少（低或高或中）
...
我被要求设计一个数据库，显示关系表以及它们之间的关系！：S：S这看起来一点也不像“学生班”数据库”或我遇到的“CD 公司数据库”！这只是..我不知道..动态:s:s
我不知道如何开始设计这个数据库或者我应该阅读或查看哪些内容为了为这样的数据设计一个数据库，
请帮助！
im given a hard copy of a form that is used by a hospital to gather information about its patients ! the form is divided into sections and each section has A LOT of YES/NO check boxes.
For example, one of the section is the History section that has more than 20 unrelated yes/no fields:
smoker ( yes or no)
diabetes (yes or no )
Chronic Lung (yes or no )
.
.
.
.
.
Another section is the "stress test data" section that has questions like the following:
Standard test (yes/no) , if yes , what are the results ( negative or positive),
if positive ( what is the extent (low or high, or intermediate )
...
i am asked to design a database, show the relation tables and the relation between them ! :S:S this is looks NOTHING like the "student-class database" or the "CD company database" i came across ! this is just..i dont know..DYNAMIC :s:s
i have NO IDEA how to even START designing this database or what are the things that i should read or look into or practice in order to design a database for such a data!
PLEASE HELP !!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
看一下这两个 SO 示例：
Take a look at these two SO examples:
看一下EAV（实体属性值）数据库设计方案。
您不必专门使用它，只需用于动态数据即可。它会让你的那部分查询变得有趣吗？是的。但购买了令人难以置信的灵活性。顺便说一句，我已成功地将 EAV 方案用于多个 EHR/EMR 项目。
Take a look at the EAV (Entity Attribute Value) Database Design scheme.
You don't have to use it exclusively, just for your dynamic data. Will it make that part of your queries interesting? Yes. But buys an incredible amount of flexibility. Btw, i've used the EAV scheme for several EHR/EMR projects succesfully.
有两种基本方法可以做到这一点。无论哪种情况，您都会有一个患者表，其中包含患者的 ID 号、姓名，可能还包括联系信息。
然后，您可以向该表添加列（即吸烟者列，1 表示是，0 表示否），并且您可以添加与患者的每个属性相对应的一大堆列。
另一种（恕我直言，更好）是保留患者表，然后添加属性表。属性表将包含 PatientID、attributeName 和 attributeValue 列。因此，对于吸烟者，您将获取患者 ID 并在 (id, "smoker", 1) 的属性表中添加一行，然后继续这样添加。然后，您必须编写查询以从属性表中获取有关给定患者的所有信息，但这是另一个挑战......
Well there are two basic ways you can do this. You'll have a patients table in either case with the patient's id number, name, and maybe contact information.
Then, you can either add columns to this table (i.e. smoker column which would either be 1 for yes or 0 for no), and you could add a whole bunch of columns corresponding to each of the attributes of the patients.
The other (and better, IMHO) would be to leave the patients table alone, and then add an attributes table. The attributes table would have columns of patientID, attributeName, and attributeValue. So for a smoker, you would take the patient ID and add a row in the attributes table of (id, "smoker", 1) and continue adding like that. Then you have to write queries to get all the information about a given patient from the attributes table, but that's another challenge...
看看 Martin Fowler 的“分析模式”。他很好地解释了医疗保健系统的一些不错的对象模型。我认为它也可能会给你一些关于数据模型的好主意。
从物体开始，其余的就会随之而来。
Have a look at Martin Fowler's "Analysis Patterns". He does a nice job of explaining some nice object models for health care systems. I think it might give you some good ideas on the data model as well.
Start with the objects, and the rest will follow.
在继续在关系数据库中进行设计之前，请尝试想象它是否易于维护。在实践中，许多此类系统试图打破关系模型 - 这是非常经典的情况，您有表单，每个表单都有字段，没有一个字段彼此相关，每个患者都有表单和字段的副本， 等等。
与关系模型相比，我更喜欢这个。研究一下 Couch DB 等项目，它们是以文档为中心的数据库，而不是您习惯于使用表和模式等看到的模式。
探索 CouchDB、Mnesia 或其他非关系数据库。获取一本有关该主题的书，并找到以惯用的方式设计此类系统的最佳方法。
实际上，这些类型的系统就像实体属性值数据库，只不过它们可以很好地搜索和索引。
Before you proceed with your design in a relational database, try to imagine whether it's going to be easy to maintain. In practice, many of these kinds of systems attempt to break the relational model -- this is pretty classic case where you have forms, each form has fields, none of the fields are related to each other, each patient has copies of forms and fields, and so on.
I would strongly prefer this over a relational model. Look into projects such as Couch DB, which are document-centric databases instead of the mode you're used to seeing with tables and schemas and such.
Poke around CouchDB, Mnesia, or other non-relational database. Get a book on the subject and found out the best way to design these sorts of systems in an idiomatic manner.
In practice, these sorts of systems are like entity-attribute-value databases, except they can be nicely searched an indexed.
你所说的“动态”是什么意思？看起来您有一组相当标准的有关患者的数据要存储。我给您的建议是对数据进行建模：患者及其属性。不要尝试对调查问卷进行建模。用于收集数据的方法是无关紧要的，表单设计与数据库设计没有太大关系。
What do you mean by "dynamic"? Seems like you have a fairly standard set of data about patients to be stored. My advice to you would be to model that data: patients and their attributes. Do not attempt to model a questionnaire. The means used to gather that data is irrelevant and the form design has nothing much to do with database design.