Страницы: 1 2 След.
RSS
Вопрос по access, учет многодетных семей.
 
Всем доброго времени суток.
Благодаря данному форуму и его специалистам, решил много разных вопросов. многие из которых решались простым поиском по форуму. За что Огромное всем спасибо.
НО вот такого решения не нашел.
Решено создать базу учеников школы - в access, как она будет организована, какой функционал будет иметь, еще не известно.
Но встал вопрос выделять многодетные семьи и учеников из них, введение атрибута по принципу включено выключено (1:0) не работает так как есть целые семьи однофамильцы, а также усыновленные (или оформлен патронаж) дети.
Вопрос как в access пометить запись о ребенке, что он входит в конкретную многодетную семью? Как решение представляется использовать нумерацию, 1 многодетная семтья, 2-я, 3-я и т.д.
Но решение кажется не алё, нет ли каких других решений?
Для вывода в таблицу.
Всего многодетных семей в школе.
Кол-во детей в многодетных семьях.
Из них кол-во детей многодетных семей учащихся в школе.
Изменено: Николай - 19.12.2015 08:06:40
 
Цитата
Николай написал: решение кажется не алё
Почему нет? Создаёте отдельную таблицу Многодетные семьи с полями Код, ФИО матери, ФИО отца, кол-во детей, адрес, телефон и т.д. А уже для ребёнка указываете код семьи.
 
Pelena, Понял спасибо.
Цитата
Pelena написал:
Почему нет?
Предполагал, (надеялся), что есть другие решения.
 
Цитата
Николай написал:
Предполагал, (надеялся), что есть другие решения.
Прежде чем заниматься базами данных, вы хоть узнали, что это такое? Вы знаете правила нормализации и зачем они нужны?
There is no knowledge that is not power
 
Цитата
SuperCat написал:
Вы знаете правила нормализации и зачем они нужны?
нет не знаю.
Но так понимаю очень важные правила. Значит надо будет обязательно ознакомится с ними.
Спасибо, что помогаете.
 
Прежде чем начинать создавать базы, надо познакомиться с теорией дизайна баз данных. Скажу сразу - это штука непростая как кажется на первый взгляд. Я русских авторов не читал, поэтому у меня только английская литература. Могу посоветовать хорошие книги:
1) Pro SQL Server 2008 Relational Database Design and Implementation (автор Louis Davidson)
2) Beginning Database Design (автор Gavin Powell)
По первой книге - читать первые 4 главы. Во второй - тоже первые 4 главы.
Удачи.
There is no knowledge that is not power
 
SuperCat,
Спасибо.
Ознакомился с правилами нормализации, как сказано в одной из статей, важны первые три.
Прочитал объяснения с примерами, в принципе дельно написано, но как вы правильно сказали просто кажется только на первый взгляд.
Пошел изучать перевод книг.
 
Я бы поставил данную книгу во главу теории (имхо конечно)
 
Цитата
B.Key написал:
Я бы поставил данную книгу во главу теории (имхо конечно)
Давайте разберёмся по порядку.
Эта книга НЕ о теории баз данных, а описание двух последних фаз дизайна БД, поэтому логично, что книга начинается с определения "реляционной базы данных". Согласно книге Louis Davis'а, в дизайне БД есть 4 фазы (полное описание этих фаз - на странице 3):
1) Conceptual
2) Logical
3) Implementation
4) Physical
B.Key, указанная тобою книга описывает фазы 3 и 4, а первых двух - самых важных - нет. Поэтому прежде чем советовать какие-либо книги, надо понимать, что советовать, так как ТС не в теме вообще. Если быть более конкретным, то итоговая схема рождается в фазе 2. Для этого используются специальные программы для отрисовки таких диаграмм - например, Visio.
There is no knowledge that is not power
 
А вообще по сути вопроса. Здесь будет связь "многие-ко-многим" (many-to-many). Можно рульнуть так:
There is no knowledge that is not power
 
Цитата
SuperCat написал:
Здесь будет связь "многие-ко-многим" (many-to-many)
Я пока дошел только до "один-ко-многим"
Интересный блок статей нашел на хабре.
Благодаря вам между прочим, рухнула надежда быстренько склепать базу данных, на основе имеющейся таблицы, в которой черт ногу сломит. Но при этом в ней не хватает необходимых данных, поленились занести, когда поняли что excel им не поможет. Посему придется наверное заносить всех по новой.
Из школьной жизни:
На данный момент, например,  для выборки количества детей для новогодних подарков. (все с 1-4 класс,  + из многодетных семей все до 9 включительно. + тем кого воспитывают бабушка с дедушкой (собственно самим бабе и деду), + детям из многодетных семей которые ходят на подготовительные занятия (в следующем году пойдут в первый класс) + также до трех лет детям из многодетных семей чьи братья или сестры учатся в школе) социальный работник уходит с головой, в прямом смысле, в кучу бумажек и считает это количество.  
Читая правила нормализации и связанные с этим статьи, я четко понимаю, что считать вручную ей придется еще ой как долго.
Поэтому на данный момент, просто хочу составить элементарную базу данных, чисто по ученикам например.
Продумать как их перемещать из класса в класс, выпускать из школы (чтобы после постановки какой либо метки (год выпуска например), данный ученик не появлялся в каких либо списках учащихся, НО был доступен при построении таблицы выпускников по годам ну или еще как.
при этом работать буду со списком ну пусть будет 10-20 человек, для простоты понимания поставленной пере домной задачи.
SuperCat, если возможно, то посоветуйте пожалуйста хороший форум, на подобие этого, по Access 2013.
 
Так же сразуже встает вопрос как добавлять новых детей чьи братья или сестры уже учатся в школе, ведь имена родителей и адрес уже известны, как реализовать такое?
Нужно наверное что-то типа поиска по базе при вводе например фамилии родителя, это первое что приходит на ум, при этом в выпадающем тексте должны быть данные которые могли бы однозначно идентифицировать семью, адрес места жительства например.
Надеюсь я смог понятно изложить.
Изменено: Николай - 20.12.2015 10:41:48
 
Цитата
Николай написал: форум, на подобие этого, по Access 2013
по совету от Михаил Лебедев - http://hiprog.com/forum/
Цитата
Николай написал: что-то типа поиска по базе
! всё SQL-запросами  - http://www.sql.ru/forum/access
(можно вытянуть, что душе угодно, если правильно организовать связи между сущностями изначально - п.1 и п.2 из #9 - в специфику вашей орг.структуры никто так хорошо не вникнет, как вы сами сможете вспомнить, что вам надо от вашей бд...)
Цитата
Николай написал: для простоты понимания поставленной пере домной задачи.
с пунктом номер 0 - вы справились
Цитата
Николай написал: Надеюсь я смог понятно изложить.
пункт №1 - порисуйте схемы, как в #10 - отобразив имеющиеся, интересующие вас, логические связи между различными таблицами, которые собираетесь внедрить в бд - структуру таблиц и связи между ними продумать лучше изначально, чтобы потом не было, как с excel (когда таблицей становится уже не удобно пользоваться)... УЧТИТЕ, что согласно связям, заданным на начальном этапе (логическим!!), - вы потом и сможете тянуть нужную инфо в любых выборках (SQL-запросах!) согласно ваших потребностей... как зададите связи между имеющейся инфо, так и вытянете потом по этим связям любое интересующее... (логически!)
p.s.
задачи, поставленные перед вами - это всё-таки ваше дело, поэтому и способы реализации могут быть известны только вам, чтобы на ветке никто не впрягался во все нюансы (их везде много), но вы смогли спросить всё, что интересует ! технически - лучше от формулировки задач переходите к проработке возможностей Access (раз выбрали её)... а уже соединить её возможности, знания форумчан и свои задачи - дело сугубо личное  ;) ... доп. линки оставила в начале поста... успехов    
Изменено: JeyCi - 20.12.2015 11:57:17
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
Николай написал:
SuperCat, если возможно, то посоветуйте пожалуйста хороший форум, на подобие этого, по Access 2013.
Цитата
Николай написал:
Так же сразуже встает вопрос как добавлять новых детей чьи братья или сестры уже учатся в школе, ведь имена родителей и адрес уже известны, как реализовать такое?
Ещё раз повторюсь: Access, SQL Server, MySQL, PostgreSQL и т.д.  - НЕ ИМЕЮТ НИКАКОГО ОТНОШЕНИЯ К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ!!!
Прочитайте ещё раз повнимательней моё сообщение #9 - вы бросаетесь сразу к пункту 3, когда у вас нет пунктов 1 и 2. Один пункт вытекает из предыдущего. Вы пытаетесь сразу слепить БД в "Access 2013", не имея архитектуры и бизнес-логики, поэтому у вас и каша.
Если бы вы прочитали первые три главы книги Louis Davis'а, то вы бы поняли, как реализуется бизнес-логика. Четвёртая глава - о нормализации - это, коротко говоря, конкретизация, оптимизация и устранение аномалий в вашей концептуальной модели.
Поэтому вам не "форум по Access 2013" нужен, а книги по дизайну баз данных (есть ещё для начинающих "Beginning Database Design From Novice to Professional", автор Clare Churcher). Увы, если вы этого не поймёте, то мне больше нечего сказать.
Сказав вам про "многие-ко-многим", вы меня не поняли и улезли в какие-то дебри. Такая ситуация - родители и дети - рулится второй формой нормализации, но вы меня не поняли. Поясню. Муж и жена могут иметь несколько детей, но и дети могут иметь несколько родителей (например, "биологических" и приёмных). Такая ситуация решается с помощью третьей таблицы, и такая связь называется "многие-ко-многим". Опять же - что такое семья? Нужно ли дальнейшее дробление семьи? Например, нужно ли знать, сколько раз был женат мужчина? Если да, то он может принадлежать нескольким семьям. Здесь опять связь "многие-ко-многим". Таким образом, всё зависит от бизнес-логики.

P.S. Схема в сообщении #10 решает вопрос соотношения детей и семей, если, конечно, не нужна дальнейшая разбивка сущности "семья".
P.P.S. На это схеме тип линии, закруглённость углов, перекладины говорят определённые вещи. Например, закруглённая таблица "Ребёнок семья" является  "зависимой сущностью" (depended entity), то есть она не может существовать сама по себе. Таблицы с острыми углами - независимые сущности. И так далее. Это уже определённый язык моделирования. Их существует несколько видов. Данный язык - IDEF1X.
Изменено: SuperCat - 20.12.2015 12:40:49
There is no knowledge that is not power
 
Цитата
JeyCi написал:
технически - лучше от формулировки задач переходите к проработке возможностей Access (раз выбрали её)
JeyCi, прочитайте моё сообщение #14 и поймёте, что Access совсем ни при чём.
Чтобы перейти к Access, у TC'а должна быть ГОТОВАЯ ЛОГИЧЕСКАЯ СХЕМА.
Не вводите человека в заблуждение.
There is no knowledge that is not power
 
в #13 тоже ссылалась на логику...
а вот выбор бд - не считаю заблуждением, т.к. для некоторых придётся и операционку др. ставить (Linux или Mac вместо Windows)... будет ещё больше дебрей...
p.s.
Access-то не при чём без понимания основ, но если ТС выбирает реализовывать реальные свои практические задачи через приложение Access (после знакомства с основами архитектуры бд, любой) - то почему это приложение не может послужить для тренировок создания связей и знакомства с результатами выборок... чтобы не отрывать теорию от практики...-  что делаем на основе, полученных знаний, и что получаем на выходе - некоторым удобнее увидеть результат своих проб (через любое приложение), чтобы понять, как работает общая идея...
Цитата
SuperCat написал: у TC'а должна быть ГОТОВАЯ ЛОГИЧЕСКАЯ СХЕМА.
согласна... и должно быть понимание, что дальше... - чтобы не отрывать цели и задачи от имеющихся возможностей и потребностей (кстати по ходу знакомства с темой можно видоизменять что угодно из этой четвёрки - не теряя суть)... всё в руках ТС
Изменено: JeyCi - 20.12.2015 13:04:20
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, Сообщение #16 - абсолютно НЕВЕРНО, потому что - ещё раз повторюсь - ДИЗАЙН БАЗЫ ДАННЫХ НЕ ЗАВИСИТ ОТ ПЛАТФОРМЫ ЕЁ РЕАЛИЗАЦИИ. Мою схему я могу реализовать как в Access, так и в SQL Server'е и MySQL. Больше я повторять не буду.
Из-за такого мышления у людей появляются кривые базы данных, с которыми невозможно работать.
There is no knowledge that is not power
 
Цитата
SuperCat написал: Больше я повторять не буду.
взаимно... т.к. главное даже подчеркнула... а подмена понятий в чужом восприятии главного и второстепенного в моей речи - это не мои проблемы  ;)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
SuperCat написал:
Из-за такого мышления у людей появляются кривые базы данных, с которыми невозможно работать.
Оно понятно.
Для меня ясна позиция как SuperCat, так и JeyCi, спасибо вам огромное.
Теперь по пунктам.
1. Конечно иметь план (схему) при создании БД, необходимо это факт.
2. Но мне мало получить теорию по созданию схемы, мне важно знать смогу ли я это вообще реализовать, а отсюда
3. Подход JeyCi, очень импонирует, просто создать какую либо БД и поиграться с ней, так сказать увидеть, что это такое. По пути изучая те или иные аспекты как реализации базы, так и конструктивно схематические. А потом уже п.1 НО
4. Наличие теории создания БД конечно необходимо, а то получишь просто фигню, а не БД.
Посему хочу попробовать на простейшем примере. За основу возьму схему их поста #10, если SuperCat,  не против конечно?
Изменено: Николай - 20.12.2015 13:25:18
 
Николай, У JeyCi нет никакого подхода - это просто какой-то симбиоз понятий: немного оттуда, немного отсюда. Короче, как в песне "Я тебя слепила из того, что было".  
Цитата
Николай написал:
Но мне мало получить теорию по созданию схемы, мне важно знать смогу ли я это вообще реализовать, а отсюда
Конечно, можно. На то они и RDBMS, чтобы реализовывать такие схемы.
Цитата
Николай написал:
Наличие теории создания БД конечно необходимо, а то получишь просто фигню, а не БД.
Вот это уже верное направление мыслей. :) Нельзя создавать БД в терминах таблицы - они будут созданы в третьей фазе процесса архитектуры.
Есть даже специальные книги по физическому дизайну баз данных - например, "Physical Database Design". Это тоже целая наука.
Поэтому дизайн БД надо создавать правильно, по этапам, которые друг от друга зависят. Нет, ну если в голове сразу рисуются корректные сущности и связи между ними, то можно сразу приступить к переносу схемы в СУБД.
Цитата
Николай написал:
За основу возьму схему их поста #10, если SuperCat,  не против конечно?
Пользуйтесь на здоровье. :)
Изменено: SuperCat - 20.12.2015 13:46:58
There is no knowledge that is not power
 
SuperCat,
Кривая схема, которая сразу бросается в глаза об отсутствии практического опыта проектирования БД.
Или Вы специально Старт топику неправильную структуру впариваете?
=========
Если Вы позиционируете себя как супер пупер мега специалист (Я себя таким не считаю), не делайте простейших ошибок как в посте
Тынц
 
Цитата
B.Key написал:
Кривая схема
Чё обиделся? :) Да ладно, не плачь.
There is no knowledge that is not power
 
Цитата
B.Key написал: Кривая схема
Можете аргументировать, в чём кривизна? (интересуюсь для расширения кругозора) Спасибо.

Формула массива (ФМ) вводится Ctrl+Shift+Enter
Memento mori
 
Цитата
JayBhagavan написал:
Можете аргументировать, в чём кривизна?
Да он обиделся на сообщение #9
There is no knowledge that is not power
 
SuperCat, я не телепат и не настолько хорошо разбираюсь в людях чтобы со 100% уверенностью утверждать, что ответ продиктован эмоциями. Возможно и да, а возможно и нет. Подождём уважаемого B.Key.

Формула массива (ФМ) вводится Ctrl+Shift+Enter
Memento mori
 
Цитата
JayBhagavan написал:
Возможно и да, а возможно и нет.
Если бы это были не эмоции, то ответ был бы аргументированным. Тем более я уверен, что B.Key даже и не понял, что это вовсе не финальная единственно правильная схема, а лишь набросок, направление. Можно было бы вообще без атрибутов схему нарисовать - с одними ID, но принцип реализации "многие-ко-многим" именно такой.
Но ещё раз повторюсь - всё зависит от бизнес-логики ТС'а. Что-то наверняка надо будет добавить, а что-то и вынести в отдельную сущность. Другими словами, не всегда сущность в логической схеме будет соответстовать одной таблице в RDBMS.
Изменено: SuperCat - 20.12.2015 22:39:02
There is no knowledge that is not power
 
SuperCat, спасибо за Ваш ответ. Мне интересно мнение разных профессионалов. Ваше в том числе, какое бы оно едкое, порой, ни было. :)

Формула массива (ФМ) вводится Ctrl+Shift+Enter
Memento mori
 
Ух-ты какие у вас тут дебаты развернулись.
По теме:
на данный момент, следуя совету SuperCat, изучаю теорию, на что естественно требуется время.
Посему непосредственно само создание БД отложено на неопределенный срок.
Ввиду того, что работаю на чистом альтруизме, и чтение по теме далеко не рассказы Артура Конан Дойля, то на долго меня не хватает, максимум пара часов, с перерывом минимум на 3-4 часа.
 
Цитата
Николай написал:
далеко не рассказы Артура Конан Дойля, то на долго меня не хватает, максимум пара часов, с перерывом минимум на 3-4 часа

На мой взгляд, более эффективно совмещать теорию с практикой. Может нет смысла откладывать создание БД? Попробуйте делать БД параллельно.
 
Я не хочу ни с кем вступать в полемику, каждый в любом случае останется при своем.
1. Почему эта книга. Книга написана на простом языке. На первом этапе знакомства с БД служит хорошим подспорьем и не отталкивает читателя. она не охватывает все теорию баз данных, о чем Вы верно написали, но эта книга проста и понятна.
2. По чему кусок схемы кривой, посчитайте свои ляпы сами, Вы профи в нахождении чужих ошибок и неточностей :) , или за собой трудно замечать?
Я молчу про организацию сущностей и их атрибутов, да взять хотя бы поле {ВОЗРАСТ}.
--------
Цитата
SuperCat написал:
Чё обиделся?  Да ладно, не плачь.
С Вами я не братался, да и в сыновья мне Вы наверное годитесь, плакать из за виртуального зазнайку я тоже не собираюсь.
"Че" таких слов в русском языке не встречал.
Страницы: 1 2 След.
Читают тему
Наверх