As so often the case with our data, some entries
or documents will have fields that other do not. In
any project, a data model usually goes through several literations.
MongoDB was designed to address both of these issues by providing
a flexible schema that deals well with both individual documents
that vary in the fields they contain as well as
the schema for our entire collection needing to change. Let's
take a look at person info box data, as an example.
Now for nearly everyone, it probably makes sense to
include fields for birth and death dates. Maybe nationality and
even profession, but not everyone will have held office, and
not everyone is associated with a political party. And even
if we're talking about people who are not famous,
some people will have spouses. Some will have more than
one. And others won't. Some will have children and some
will not. Leaving aside the question of what is the
right data model for person data. In MongoDB we can
represent each person using the fields that are appropriate to them
even if some person documents contain fields that others don't have.
MongoDB's indexing system and query execution system take this into account.
So we can query a people collection for people with
two or more children, and it will work as expected retrieving
only data for people that have two or more entries in
the array that serves as the value for the children field.
Ignoring documents with fewer As well as documents that don't
have a children field at all. What this also means is
that it's easy to evolve your scheme as new needs emerge
or more data becomes available. It's a simple matter to begin
adding documents to a collection that have new fields you now
want to track or to change the way you model existing
fields. As an example of this, let's take a look at
the dbpedia page, that describes the data sets that are available.
Now, if I scroll down this page. And, I've already
done that here, we have an example for city data.
So, so far we've looked at automobile data, person data
and now, city data, from the info-box data set. And, I'm
showing this example to illustrate the fact that the scheme
for city info boxes has evolved. And, we can see that
in this old example for Innsbruck. And comparing it to
the new example for Innsbruck and if you look through this
data there are a couple of places where
the data has changed. There's no mayor listed here
as there is here and while there's no time
zone listed in the old form of the data.
The time zone for central and day light
savings time are listed here. Small differences, but these
are the type of subtle changes that we would
expect to see in a schema that is evolving.
وكما هو الحال غالبًا مع البيانات، ستتضمن بعض
الإدخالات أو المستندات حقولاً لا تتضمنها الأخرى. في
.أي مشروع، يمر نموذج البيانات غالبًا عبر العديد من عمليات التعبير بالأحرف
تم تصميم MongoDB لمعالجة كل مشكلة من هاتين المشكلتين بواسطة تقديم
مخطط مرن يتعامل بشكلٍ جيد مع المستندات الفردية
التي تختلف في الحقول التي تتضمنها وكذلك
مخطط للمجموعة بأكملها التي بحاجة إلى التغيير. فلنلقِ
.نظرة على بيانات مربع معلومات شخص، كمثال
والآن بالنسبة للجميع تقريبًا، قد يكون من المنطقي
تضمين حقول لتواريخ الميلاد والوفاة. وربما للجنسية
والمهنة، لكن لن يمتلك الجميع مكتبًا
ولن يرتبط الجميع بحزب سياسي. وحتى
،إذا كنا نتحدث عن الأشخاص غير المشهورين
سيكون لبعض الأشخاص أزواج. وسيكون للبعض أكثر من
زوج. في حين لا يسري ذلك على الآخرين. وسيكون للبعض أطفال والبعض
لا. مع التغاضي عن السؤال المتعلق بما هو
نموذج البيانات المناسب لبيانات الأشخاص. في قاعدة بيانات MongoDB يمكننا
تمثيل كل شخص باستخدام الحقول المناسبه له
.حتى إذا كانت بعض مستندات الأشخاص تتضمن حقولاً لا تتضمنها المستندات الأخرى
.يضع نظام الفهرسة ونظام تنفيذ الاستعلامات لقاعدة البيانات MongoDB ذلك في الاعتبار
لذا يمكننا الاستعلام عن مجموعة أشخاص وذلك للأشخاص الذين لديهم
طفل أو اثنان وسيعمل الاستعلام كالمتوقع حيث سيتم استرداد
بيانات الأشخاص الذين لديهم إدخال واحد أو أكثر فقط في
.الصفيف الذي يعمل كقيمة لحقل الأطفال
ويتم تجاهل المستندات التي تتضمن قيمة أقل وكذلك المستندات التي لا تتضمن
حقل أطفال على الإطلاق. ما يعنيه ذلك أيضًا أنه
من السهل تطوير المخطط مع ظهور متطلبات جديدة
أو توفر المزيد من البيانات. إنه لأمر يسير أن تبدأ في
إضافة مستندات إلى مجموعة تتضمن عددًا قليلاً من الحقول التي تريد الآن
تتبعها أو تغيير طريقة تشكيل الحقول
الحالية. وكمثال على ذلك، لنلقِ نظرة على
.صفحة dbpedia، التي تصف مجموعات البيانات المتاحة
الآن، إذا قمت بالتمرير لأسفل ضمن هذه الصفحة. وقمت بإجراء
.ذلك هنا، فسيكون لدينا مثال على بيانات المدينة
إذًا، حتى الآن ألقينا النظر على بيانات السيارة وبيانات شخص
والآن، بيانات مدينة، من مجموعة بيانات مربع المعلومات. وأنا أعرض
هذا المثال لتوضيح الحقيقة التي تفيد أن مخطط
مربعات معلومات المدينة قد تطور. ويمكننا رؤية ذلك
في هذا المثال القديم لمدينة إنسبروك. ومقارنته
بالمثال الجديد لمدينة إنسبروك وإذا أمعنت النظر خلال هذه
البيانات، فستجد مكانين
تغيرت فيهما البيانات. لا يوجد رئيس بلدية مدرج هنا
كما هو هنا بينما لا توجد منطقة
.زمنية مدرجة هنا في نموذج البيانات القديم
ويتم إدراج المنطقة الزمنية للتوقيت المركزي
والتوقيت الصيفي هنا. هناك فوارق بسيطة، لكن هذه الفوارق هي
نوع التغييرات الدقيقة التي نتوقع
.رؤيتها في مخطط يتطور
Como tantas vezes acontece com nossos dados, algumas entradas
ou documentos terão campos que outros não. Em
qualquer projeto, um modelo de dados geralmente passa por várias iterações.
O MongoDB foi desenvolvido para solucionar ambos os problemas fornecendo
um esquema flexível que lida bem com documentos individuais,
cujos campos variam, e também
com o esquema para nossa coleção inteira que precisa de mudanças. Vamos
observar os dados de caixa de informações pessoais como exemplo.
Para quase todas as pessoas faz sentido
incluir campos para datas de nascimentos e falecimento. Talvez nacionalidade e
até profissão, mas nem todos terão ocupação, e
nem todos estarão associados a um partido político. E mesmo
que estejamos falando de pessoas que não sejam famosas,
algumas terão cônjuges. Algumas terão mais de
um. E outras, não. Algumas terão filhos e outras,
não. Vamos deixar de lado a pergunta sobre qual é o
modelo de dados certo para dados pessoais. No MongoDB, podemos
representar cada pessoa usando os campos que são apropriados para ela,
mesmo se os documentos de alguma pessoa contiverem campos que outros não.
O sistema de indexação e o sistema de execução de consulta do MongoDB levam isso em consideração.
Portanto, podemos consultar uma coleção de pessoas para pessoas com
dois ou mais filhos, e isso funcionará conforme esperado, recuperando
apenas dados de pessoas que têm duas ou mais entradas no
array que sirvam como valor para o campo filhos,
ignorando documentos com menos entradas, bem como documentos que não
tenham um campo filhos. Isso significa que
é fácil desenvolver seu esquema à medida que surgem novas necessidades
ou mais dados se tornam disponíveis. Basta começar
adicionando documentos a uma coleção que tenha novos campos que agora
você quer rastrear ou mudando como modela os campos
existentes. Por exemplo, vamos analisar
a página dbpedia, que descreve os conjuntos de dados que estão disponíveis.
Se eu rolar esta página para baixo, e, eu já
fiz isso aqui, temos um exemplo para dados de cidade.
Até aqui analisamos dados de automóveis, pessoas
e, agora, cidade, neste conjunto de dados de caixa de informações. Estou
mostrando este exemplo para ilustrar que o esquema
para caixas de informações de cidade evoluiu. Podemos ver isso
neste exemplo antigo de Innsbruck. E comparando-o
com o novo exemplo de Innsbruck, se você observar estes
dados, há alguns pontos em que
os dados foram alterados. Não há prefeito listado aqui
como há aqui e, enquanto não há fuso horário
listado no formulário antigo de dados,
o fuso horário central e o horário
de verão estão listados aqui. Pequenas diferenças, mas
são o tipo de mudanças sutis que esperaríamos
ver em um esquema que está evoluindo.
正如我们处理数据时经常遇到的情况那样
一些输入项或文档具有其它输入项或文档没有的字段
在任何项目中 数据模型通常经历几次叠代
MongoDB 设计用于通过提供灵活模式解决这两个问题
灵活模式很好地处理两个在
其包含的字段内变化的单独文档
以及我们整个收集需要改变的模式
作为示例 让我们看看人员信息框数据
现在 几乎对于每个人
包括出生和死亡日期字段可能都是有意义的
也许还有民族和职业 但并不是每个人都会有办公室
并不是每个人都与政党有关
即使我们谈论那些不出名的人
有些人会有配偶 有些会有不止一个配偶
而有些人没有配偶 有些会有孩子 而有些人没有孩子
撇开什么是个人数据的正确数据模型问题
在 MongoDB 中
即使有些个人文档包含其它人没有的字段
我们可以代表使用适合其字段的每个人
MongoDB 的索引系统和查询执行系统考虑到这一点
因此 我们可以查询有两个或以上儿童的人物收录
并且他将按照预期仅为
数组中具有用于儿童字段值的
两个或以上输入项的人员检索数据
忽略很少有儿童的文档以及根本没有儿童字段的文档
这也意味着
随着新需求的出现或更多数据变得可用
很容易开发你的计划
开始将文档添加到有新字段的集合中是一件很简单的事情
你现在需要跟踪或改变建立现有字段模型的方式
作为例子
让我们看一看 dbpedia 页面 该页面描述了可用的数据集
现在 如果我向下滚动该页面会发现
我已经在这里做过了 这里有一个城市数据的例子
到目前为止 我们已经看过了汽车数据 人员数据
现在 我们看过了信息框数据集的城市数据
并且 我展示这个例子来说明城市信息框计划已发展的事实
并且 我们可以在 Innsbruck 的这个旧例子中看到城市数据
并将其与 Innsbruck 的新例子进行比较
如果你仔细查看该数据
有几个地方已更改数据
这里没有列出市长
因为这里有
同时在旧数据形式中未列出时区
中央和白天时区
在这里列出节省时间 微小差异 但是这些都是
我们希望在发展模式中
看到的微妙变化类型