Voorbeeld van een sterke en zwakke entiteitstypen

Ik heb geprobeerd om op Google te kijken over een fatsoenlijke uitleg van zwak en sterke entiteitstype , maar ik heb ze niet volledig begrepen.

Kan iemand me een voorbeeld geven van een sterk en zwak entiteitstype?


Antwoord 1, Autoriteit 100%

Een zwakke entiteit is er een die alleen kan bestaan ​​als het eigendom is van een andere.
Bijvoorbeeld: een kamer kan alleen bestaan ​​in een -gebouw . Aan de andere kant kan een -band worden beschouwd als een sterke entiteit omdat het ook kan bestaan ​​zonder te worden gehecht aan een auto .


Antwoord 2, Autoriteit 42%

Gewoon spelen, vraag is een sterk entiteitstype en het antwoord is zwak. Vraag is er altijd, maar een antwoord vereist een vraag.

Voorbeeld: don ‘ vraag ‘waarom?’ Als je vader een chemieprofessor

is


Antwoord 3, Autoriteit 22%

A Zwakke entiteit is de entiteit die niet volledig kan worden geïdentificeerd door zijn eigen attributen en de buitenlandse sleutel als een attribuut inneemt (in het algemeen neemt het de primaire sleutel van de entiteit waarmee het verband houdt) in combinatie.

voorbeelden

Het bestaan ​​van kamers is volledig afhankelijk van het bestaan ​​van een hotel. Dus kamer is te zien als de zwakke entiteit van het hotel.
Een ander voorbeeld is de |
Bankrekening van een bepaalde bank heeft geen bestaan ​​als de bank niet meer bestaat.


Antwoord 4, Autoriteit 17%

Een bedrijfsverzekering verzekert een werknemer en eventuele personen ten laste, de AFHANKELIJKE kan niet bestaan zonder de WERKNEMER; dat wil zeggen, een persoon kan geen verzekeringsdekking krijgen als een persoon ten laste tenzij de persoon een persoon ten laste is van een werknemer. AFHANKELIJK is de zwakke entiteit in de relatie “WERKNEMER is AFHANKELIJK”


Antwoord 5, autoriteit 8%

Sterke entiteit

Het kan bestaan zonder enige andere entiteit.

Voorbeeld

Customer(customerid, name, surname)

Zwakke entiteit

Het hangt af van een dominante entiteit en kan niet bestaan zonder een sterke entiteit.

Voorbeeld

Adress(addressid, adressName, customerid)

Antwoord 6, autoriteit 3%

Er bestaat een zwakke entiteit om het probleem met meerdere waarden op te lossen.

Er zijn twee soorten attributen met meerdere waarden. Een daarvan is de simpelweg vele waarden voor een object zoals een “hobby” als attribuut voor een student. De student kan veel verschillende hobby’s hebben. Als we de hobby’s in de studententiteit laten staan, zou “hobby” niet meer uniek zijn. We creëren een aparte entiteit als hobby. Dan koppelen we de hobby en de leerling naar behoefte. De hobby-entiteitsset is nu een associatieve entiteitenset. Of het zwak is of niet, we moeten controleren of elke entiteit voldoende unieke identifiers heeft om het te identificeren. Volgens velen kan een hobbynaam voldoende zijn om het te identificeren.

Het andere type multi-gewaardeerd attribuutprobleem heeft wel een zwakke entiteit nodig om het te repareren. Laten we zeggen dat een item-entiteit is ingesteld in een supermarktvoorraadsysteem. Is het item een ​​categorie-item of het daadwerkelijke item? Het is een belangrijke vraag, omdat een klant tegelijk hetzelfde item en op een bepaald bedrag kan kopen, maar hij kan ook hetzelfde item op een andere tijd met een ander bedrag kopen. Kun je het hetzelfde item zien, maar van verschillende objecten. Het item is nu een kenmerk multi-gewaardeerd. We lossen het op door eerst het categorie-item te scheiden met het werkelijke item. De twee zijn nu verschillende entiteitssets. Categorie Item heeft beschrijvende kenmerken van het artikel, net als het item dat u gewoonlijk aan denkt. Werkelijk item kan geen beschrijvende attributen meer hebben omdat we geen overtollige probleem kunnen hebben. Werkelijk item kan alleen een datumtijd en het bedrag van het item hebben. U kunt ze koppelen als u nodig hebt. Laten we nu praten of iemand een zwakke entiteit van de ander is. De beschrijvende kenmerken zijn meer dan genoeg om elke entiteit te identificeren in de set van de categorie Item. Het eigenlijke artikel heeft alleen datumtijd en bedrag. Zelfs als we alle kenmerken in een record uithalen, kunnen we de entiteit nog steeds niet identificeren. Denk erover na dat het alleen maar tijd en bedrag is. De eigenlijke item-entiteitsset is een zwakke entiteitsset. We identificeren elke entiteit in de set met behulp van dubbele prime-toets uit de set van de categorie Item.


Antwoord 7, Autoriteit 3%

./ Database / DataModels / RelationalDatamodel / Zwakte

Het kan waarschijnlijk in twee factoren worden geschreven:

  • afhankelijkheid: hangt af van het bestaan ​​van een identificerende entiteitsset (totaal, één-op-veel-relatie).
  • Identificatie: heeft geen primaire sleutel. Het heeft een gedeeltelijke sleutel (of discriminator). Het moet de primaire sleutel van een andere tabel gebruiken voor identificatie.

Als we zouden denken aan een database met vragen en antwoorden, dan zouden de vragen de sterke entiteit zijn en de antwoorden de zwakke entiteit.
Dus Vraag (id, tekst)en Antwoord (nummer, vraag_id, tekst)zouden onze tabellen zijn. Maar waarom is de antwoordtabel een zwakke entiteit?

  • Afhankelijkheid van de vragentabel.Elk antwoord is gekoppeld aan één vraag (aanname) en kan dus niet op zichzelf staan. Daarom hebben we mensen die één vraag stellen en deze zelf beantwoorden, zodat ze andere mensen kunnen helpen en wat extra likes krijgen.

  • Identificatie van de primaire sleutel van de vraag. Men zou geen antwoord kunnen identificeren (ervan uitgaande dat de id een identificatienummer is) omdat een vraag kan worden beantwoord door antwoorden waarvan de identificatie ook in andere vragen kan voorkomen. Primaire sleutel van de antwoordtabel: (getal, vraag_id).


Antwoord 8, autoriteit 2%

Zwakke entiteitenworden ook afhankelijke entiteitengenoemd, omdat het bestaan ervan afhangt van andere entiteiten. Dergelijke entiteiten worden weergegeven door een rechthoek met dubbele omtrek in het E-R-diagram.

Sterke entiteitenworden ook wel onafhankelijke entiteiten genoemd.


Antwoord 9

Na een paar uur door zoekmachines te hebben gebladerd, kwam ik hier een site tegen met een geweldig ERD-voorbeeld: http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html

Ik heb de ERD opnieuw gemaakt. Helaas hebben ze de primaire sleutel van de zwakke entiteit niet gespecificeerd.

Als het gebouw slechts één en slechts één appartement kan hebben, lijkt het erop dat het gedeeltelijke discriminator-kamernummer niet zou worden gemaakt (d.w.z. weggegooid).


Antwoord 10

Zwakke entiteitstype:
Een entiteit waarvan de gevallen niet kan worden afgesloten zonder te worden gekoppeld aan instanties van een andere entiteit wordt zwak entiteitstype genoemd. Het kan niet onafhankelijk bestaan.
Bijvoorbeeld: onze pc is afhankelijk van ons. Het zal niet openen of sluiten met zijn eigen.

Sterke entiteitstype:
Een entiteit waarvan de gekoppeld is aan de instanties van een ander entiteitstype een sterk entiteitstype wordt genoemd. Het kan onafhankelijk afsluiten.
Bijvoorbeeld: een persoon kan alles doen kan overal gaan en ooit ding gebruiken


Antwoord 11

Een gegevensobject dat kan bestaan ​​zonder afhankelijk van het bestaan ​​van een ander gegevensobject bekend is als sterk data-object.


Antwoord 12

Eerste sterke / zwakke referentietypen worden geïntroduceerd in ARC. In niet-arc toewijzen / behouden worden gebruikt.
Een sterke referentiemiddelen die u wilt “eigen” het object dat u verwijst met deze eigenschap / variabele. De compiler zorgt ervoor dat elk object dat u aan deze accommodatie toewijst, niet zal worden vernietigd, zolang u er naar wijst met een sterke referentie. Pas zodra u het onroerend goed instelt aan nul, wordt het object vernietigd.

Een zwakke referentiemiddelen die u aangeeft dat u geen controle wilt hebben over het leven van het object of niet wilt “eigen voorwerp”. Het object dat u verwijst naar zwak alleen leven op, omdat ten minste één ander object er een sterke verwijzing naar heeft. Zodra dat niet langer het geval is, wordt het object vernietigd en wordt uw zwakke eigenschap automatisch ingesteld op nul.
De meest voorkomende gebruiksgevallen van zwakke referenties in iOS zijn voor Iboutlets, afgevaardigden enz.

Zie voor meer informatie: http://www.informit .com/articles/article.aspx?p=1856389&seqNum=5

Other episodes